কেন এটি থ্রেডসেফ নয় সে সম্পর্কে আপনার প্রশ্নের উত্তর দেওয়ার জন্য, কারণ এটি নয় যে প্রথম কলটির জন্য instance()কনস্ট্রাক্টরকে কল করতে হবে Singleton s। থ্রেডসফেট হওয়ার জন্য এটি একটি সমালোচনামূলক বিভাগে ঘটতে হবে, এবং সমালোচনামূলক বিভাগটি গ্রহণের মানটির কোনও প্রয়োজন নেই (আজকের মান থ্রেডগুলিতে সম্পূর্ণ নীরব) silent সংকলকগণ প্রায়শই একটি সাধারণ চেক এবং স্ট্যাটিক বুলিয়ান বৃদ্ধির সাহায্যে এটি প্রয়োগ করে - তবে একটি সমালোচনামূলক বিভাগে নয়। নিম্নলিখিত সিউডোকোডের মতো কিছু:
static Singleton& instance()
{
static bool initialized = false;
static char s[sizeof( Singleton)];
if (!initialized) {
initialized = true;
new( &s) Singleton(); // call placement new on s to construct it
}
return (*(reinterpret_cast<Singleton*>( &s)));
}
সুতরাং এখানে একটি সাধারণ থ্রেড-নিরাপদ সিঙ্গলটন (উইন্ডোজের জন্য)। এটি উইন্ডোজ CRITICAL_SECTION অবজেক্টের জন্য একটি সাধারণ শ্রেণীর মোড়ক ব্যবহার করে যাতে আমরা সংকলকটি CRITICAL_SECTIONআগে main()বলা হওয়ার আগে স্বয়ংক্রিয়ভাবে আরম্ভ করতে পারি । আদর্শভাবে একটি সত্য RAII সমালোচনামূলক বিভাগ শ্রেণি ব্যবহার করা হবে যা সমালোচনামূলক বিভাগটি অনুষ্ঠিত হওয়ার পরে ঘটতে পারে এমন ব্যতিক্রমগুলির সাথে মোকাবিলা করতে পারে তবে এটি এই উত্তরটির পরিধি ছাড়িয়ে যায়।
মৌলিক ক্রিয়াকলাপটি হ'ল যখন কোনও উদাহরণটির Singletonজন্য অনুরোধ করা হয়, একটি লক নেওয়া হয়, সিঙ্গেলটন তৈরি করা হয় যদি এটির প্রয়োজন হয় তবে লকটি প্রকাশ করা হয় এবং সিঙ্গেলটন রেফারেন্স ফিরে আসে।
#include <windows.h>
class CritSection : public CRITICAL_SECTION
{
public:
CritSection() {
InitializeCriticalSection( this);
}
~CritSection() {
DeleteCriticalSection( this);
}
private:
// disable copy and assignment of CritSection
CritSection( CritSection const&);
CritSection& operator=( CritSection const&);
};
class Singleton
{
public:
static Singleton& instance();
private:
// don't allow public construct/destruct
Singleton();
~Singleton();
// disable copy & assignment
Singleton( Singleton const&);
Singleton& operator=( Singleton const&);
static CritSection instance_lock;
};
CritSection Singleton::instance_lock; // definition for Singleton's lock
// it's initialized before main() is called
Singleton::Singleton()
{
}
Singleton& Singleton::instance()
{
// check to see if we need to create the Singleton
EnterCriticalSection( &instance_lock);
static Singleton s;
LeaveCriticalSection( &instance_lock);
return s;
}
মানুষ - "আরও ভাল বিশ্বব্যাপী করতে" এটি প্রচুর বাজে।
এই প্রয়োগের মূল ত্রুটিগুলি (যদি আমি কিছু বাগ স্লিপ না করতাম) তা হ'ল:
- যদি
new Singleton()ছুড়ে ফেলে, লকটি প্রকাশ করা হবে না। আমার এখানে থাকা সাধারণটির পরিবর্তে সত্যিকারের আরআইআইআই লক অবজেক্টটি ব্যবহার করে এটি ঠিক করা যেতে পারে। আপনি লস্টের জন্য প্ল্যাটফর্মের স্বতন্ত্র মোড়ক সরবরাহ করতে বুস্টের মতো কিছু ব্যবহার করেন তবে এটি জিনিসগুলি পোর্টেবল করতে সহায়তা করতে পারে।
- সিঙ্গলটনের উদাহরণটি
main()কল করার পরে অনুরোধ করা হলে এটি থ্রেড সুরক্ষার গ্যারান্টি দেয় - যদি আপনি এটির আগে কল করেন (কোনও স্ট্যাটিক অবজেক্টের শুরুতে যেমন) জিনিসগুলি কাজ CRITICAL_SECTIONনাও করতে পারে কারণ সম্ভবত আরম্ভ করা হয়নি।
- প্রতিটি বার অনুরোধ করার সময় একটি লক অবশ্যই নেওয়া উচিত be আমি যেমন বলেছি, এটি একটি সহজ থ্রেড নিরাপদ বাস্তবায়ন। আপনার যদি আরও ভাল প্রয়োজন হয় (বা ডাবল-চেক লক কৌশলটির মতো জিনিসগুলি কেন ত্রুটিযুক্ত তা জানতে চান), গ্রোয়ের উত্তরে লিঙ্কিত কাগজপত্রগুলি দেখুন ।