مقدمه
پس از سال‌ها پر کردن فرم و انتظار کشیدن، بالاخره مجوز بانکی خود را گرفته‌اید. یعنی حالا رسماً می‌توانید بانک خودتان را باز کنید، هورا!
اولین اولویتتان راه‌اندازی سیستم‌های فناوری اطلاعات است. پس از یک روز کار سخت، هم‌اکنون می‌توانید حساب باز کنید و ببندید و همچنین برداشت‌ها و واریزها را انجام دهید.
چون حوصله‌ی نوشتن Test را نداشتید، از چند دوست می‌خواهید که در آزمایش سیستم کمکتان کنند. اما فقط پنج دقیقه بعد، یکی از دوستانتان ادعا می‌کند که پول از دست داده است! هرچند مطمئنید که کدتان بدون Bug است، شروع می‌کنید لاگ‌ها را بررسی کنید تا بفهمید چه شده است.
آهان، دقیقاً همان‌طور که حدس می‌زدید، مقصر خود دوستتان است! او اطلاعات ورود آزمایشی‌اش را با دوست دیگری به اشتراک گذاشت و با هم توطئه کردند تا به‌صورت موازی از همان حساب واریز و برداشت انجام دهند. چه کسی چنین کاری می‌کند؟
در حالی که شما بحث می‌کنید که از نظر فیزیکی غیرممکن است کسی به‌صورت موازی به حساب خود دسترسی پیدا کند، دوستتان با خودپسندی به شما اطلاع می‌دهد که قوانین بانکی ملزمتان می‌کند که از این پشتیبانی کنید. بنابراین، بدون پشتیبانی از بانکداری موازی، سیگنالی برای راه‌اندازی در کار نیست. آهی می‌کشید و در ذهن خود یادداشت می‌کنید که فردا به این موضوع رسیدگی کنید. این کار تاریخ راه‌اندازی شما را حداقل یک روز دیگر عقب می‌اندازد، اما خب...
دستورالعمل‌ها
وظیفه‌ی شما پیاده‌سازی حساب‌های بانکی‌ای است که از باز کردن و بستن، برداشت و واریز پول پشتیبانی می‌کنند.
از آنجا که می‌توان از راه‌های گوناگون به حساب‌های بانکی دسترسی داشت (اینترنت، تلفن همراه، کسرهای خودکار)، نرم‌افزار بانکی شما باید طوری باشد که بتوان به‌طور موازی و ایمن از چند ریسمان/فرایند (اصطلاح آن بسته به زبان برنامه‌نویسی شما متفاوت است) به حساب‌ها دسترسی داشت.
برای نمونه، ممکن است واریزها و برداشت‌های زیادی به‌طور موازی رخ دهند؛ باید مطمئن شوید که میان خواندن موجودی حساب و تنظیم موجودی جدید، «شرایط رقابتی» رخ نمی‌دهد.
بستن حساب باید ممکن باشد؛ عملیاتی که روی حساب بسته انجام می‌شود باید با شکست مواجه شود.
پیاده‌سازی
این تمرین مفهوم «همزمانی» را معرفی می‌کند.
برای قبول شدن در آخرین test، ممکن است «کلیدواژه‌ی synchronized» یا «قفل‌ها» برایتان مفید باشد.
مشکلاتی که از اجرای همزمان code پیش می‌آیند اغلب پراکنده‌اند، چون به ترتیبی بستگی دارند که code اجرا می‌شود.
به همین دلیل، آخرین test چندین ترد را بارها اجرا می‌کند تا احتمال پیدا کردن bug را بالا ببرد.
یعنی اگر پیاده‌سازی شما «ایمن در برابر ترد» نباشد، این test باید شکست بخورد، اما این احتمال هم هست که فقط به این دلیل قبول شود که هیچ تلاشی برای تغییر همزمان انجام نشده است.
بعید است این اتفاق چند بار پشت سر هم بیفتد، چون ترتیبی که code اجرا می‌شود باید هر بار که test را اجرا می‌کنید متفاوت باشد.
پس اگر آخرین test را چند بار اجرا کنید و هر بار قبول شود، می‌توانید نسبتاً مطمئن باشید که پیاده‌سازی شما درست است.
