.NET- এ ডাবল চেকড লকিংয়ে অস্থির পরিবর্তনকারীগুলির প্রয়োজন

Question 1

একাধিক পাঠ্য বলেছেন যে .NET ফিল্ডটিতে ডাবল-চেকড লকটি প্রয়োগ করার সময় আপনি যে ক্ষেত্রটি লক করছেন তাতে অস্থির পরিবর্তনকারী প্রয়োগ করা উচিত। তবে ঠিক কেন? নিম্নলিখিত উদাহরণ বিবেচনা:

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

"লক (সিঙ্করুট)" প্রয়োজনীয় মেমরির ধারাবাহিকতা কেন সম্পাদন করে না? এটা কি সত্য নয় যে "লক" বিবৃতিটি পড়া এবং লেখা উভয়ই অস্থির এবং তাই প্রয়োজনীয় ধারাবাহিকতা সম্পন্ন হবে?

Question 2

অস্থিরতা অপ্রয়োজনীয়। ভাল ধরণের**

volatileচলকটিতে পঠন এবং লেখার মধ্যে একটি মেমরি বাধা তৈরি করতে ব্যবহৃত হয়।
lockব্যবহার করা হলে, ব্লকের lockঅ্যাক্সেসকে একটি থ্রেডে সীমাবদ্ধ করা ছাড়াও এর ভিতরে থাকা ব্লকের চারপাশে মেমরির বাধা তৈরি করে ।
মেমোরি বাধা এটি তৈরি করে যাতে প্রতিটি থ্রেড চলকটির সর্বাধিক বর্তমান মান পড়ে (কোনও রেজিস্টারে ক্যাশে থাকা স্থানীয় মান নয়) এবং যে সংকলক বিবৃতিগুলি পুনরায় অর্ডার করে না। ব্যবহার volatileকরা অপ্রয়োজনীয় ** কারণ আপনি ইতিমধ্যে একটি লক পেয়েছেন।

জোসেফ আলবাহারী এই জিনিসটিকে আমার চেয়ে আরও ভালভাবে ব্যাখ্যা করে।

এবং সি # তে সিঙ্গেলটন বাস্তবায়নের জন্য জোন স্কিটের গাইড পরীক্ষা করে দেখতে ভুলবেন না

আপডেট :
* volatileভেরিয়েবলটি পড়ার কারণ হতে পারে VolatileReadএবং এস হতে লেখায় VolatileWrite, যা এক্স 86 এবং সিএলআর এক্স x64 এর সাথে প্রয়োগ করা হয় MemoryBarrier। তারা অন্যান্য সিস্টেমে সূক্ষ্ম দানাযুক্ত হতে পারে।

** আমার উত্তরটি কেবলমাত্র সঠিক যদি আপনি x86 এবং x64 প্রসেসরের সিএলআর ব্যবহার করেন। এটি অন্যান্য মেমোরি মডেলগুলিতে সত্য হতে পারে যেমন মনো (এবং অন্যান্য বাস্তবায়ন), Itanium64 এবং ভবিষ্যতের হার্ডওয়্যারগুলির মতো। ডাবল চেক লকিংয়ের জন্য জনের "গেটচস" এ তার নিবন্ধে এটি উল্লেখ করা হয়েছে।

দুর্বল মেমরি মডেলের পরিস্থিতিতে কোডটি সঠিকভাবে কাজ করার জন্য - কোনওটি ভেরিয়েবল হিসাবে চিহ্নিত করা volatile, এটি পড়ার সাথে Thread.VolatileReadবা একটি কল সন্নিবেশ করানো Thread.MemoryBarrierপ্রয়োজন হতে পারে।

আমি যা বুঝি সেগুলি থেকে, সিএলআর (এমনকি আইএ 64৪ তেও), লেখাগুলি কখনই পুনরায় অর্ডার হয় না (লেখাগুলি সর্বদা প্রকাশের শব্দার্থক থাকে)। তবে, আইএ 64৪-তে, পাঠগুলি লেখার আগে আসার জন্য পুনঃক্রম হতে পারে, যদি না সেগুলিকে অস্থির চিহ্নিত করা হয়। দুর্ভাগ্যক্রমে, আমার সাথে খেলতে আইএ 64৪ হার্ডওয়্যারটিতে অ্যাক্সেস নেই, তাই আমি এ সম্পর্কে যা কিছু বলি তা জল্পনা ছিল।

আমি এই নিবন্ধগুলি সহায়কও পেয়েছি:
http://www.codeproject.com/KB/tips/MemoryBarrier.aspx
ভ্যান্স মরিসনের নিবন্ধ (এর সাথে সমস্ত লিঙ্ক, এটি ডাবল
চেকড লকিংয়ের বিষয়ে কথা বলে) ক্রিস ব্রুমের নিবন্ধ (এর সাথে সমস্ত লিঙ্ক ) )
জো ডাফি: ডাবল চেকড লকিংয়ের ভাঙা রূপগুলি

লুইস অ্যাব্রেয়ের সিরিজ মাল্টিথ্রিডিংয়ে ধারণাগুলিরও একটি সুন্দর ওভারভিউ দেয়
http://msmvps.com/blogs/luisabreu/archive/2009/06/29/multithreading-load-and-store-reordering.aspx
http: // msmvps। com / ব্লগস / লুইসাব্রেউ / সংরক্ষণাগার / 2009/07/03 / মাল্টিথ্রেডিং-পরিচয়-মেমরি-fens.aspx

Question 3

volatileমাঠ ছাড়াই এটি বাস্তবায়নের একটি উপায় রয়েছে । আমি এটি ব্যাখ্যা করব ...

আমি মনে করি এটি লকটির অভ্যন্তরে মেমরি অ্যাক্সেসকে পুনরায় সাজানো যা বিপজ্জনক, যেমন আপনি লকের বাইরে সম্পূর্ণরূপে প্রাথমিক সূচনা পেতে পারেন না। এটি এড়াতে আমি এটি করি:

public sealed class Singleton
{
   private static Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         // very fast test, without implicit memory barriers or locks
         if (instance == null)
         {
            lock (syncRoot)
            {
               if (instance == null)
               {
                    var temp = new Singleton();

                    // ensures that the instance is well initialized,
                    // and only then, it assigns the static variable.
                    System.Threading.Thread.MemoryBarrier();
                    instance = temp;
               }
            }
         }

         return instance;
      }
   }
}

কোড বোঝা যাচ্ছে

কল্পনা করুন যে সিঙ্গলটন ক্লাসের কনস্ট্রাক্টরের অভ্যন্তরে কিছু সূচনা কোড রয়েছে। ক্ষেত্রটি নতুন অবজেক্টের ঠিকানার সাথে সেট করার পরে যদি এই নির্দেশাবলী পুনরায় সাজানো হয় তবে আপনার একটি অসম্পূর্ণ উদাহরণ রয়েছে ... কল্পনা করুন যে শ্রেণিটিতে এই কোড রয়েছে:

private int _value;
public int Value { get { return this._value; } }

private Singleton()
{
    this._value = 1;
}

এখন নতুন অপারেটরটি ব্যবহার করে কনস্ট্রাক্টরের কাছে কল কল করুন:

instance = new Singleton();

এটি এই ক্রিয়াকলাপগুলিতে প্রসারিত হতে পারে:

ptr = allocate memory for Singleton;
set ptr._value to 1;
set Singleton.instance to ptr;

যদি আমি এই নির্দেশাবলীর এইরকম পুনঃক্রম করতে পারি তবে:

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
set ptr._value to 1;

এটা কি কোন পার্থক্য তৈরি করছে? আপনি যদি একক সুতোর কথা ভাবেন না । হ্যাঁ আপনি যদি একাধিক থ্রেডের কথা ভাবেন ... তবে থ্রেডটি বাধা হয়ে গেলে কি হবে set instance to ptr:

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
-- thread interruped here, this can happen inside a lock --
set ptr._value to 1; -- Singleton.instance is not completelly initialized

মেমরি অ্যাক্সেস পুনরায় ক্রমান্বয়ে অনুমতি না দিয়ে মেমরির বাধা এটাই এড়িয়ে চলে:

ptr = allocate memory for Singleton;
set temp to ptr; // temp is a local variable (that is important)
set ptr._value to 1;
-- memory barrier... cannot reorder writes after this point, or reads before it --
-- Singleton.instance is still null --
set Singleton.instance to temp;

শুভ কোডিং!

Question 4

আমি মনে করি না যে কেউ আসলেই প্রশ্নের উত্তর দিয়েছে , তাই আমি এটি দিয়ে চেষ্টা করব।

উদ্বায়ী এবং প্রথমগুলি if (instance == null)"প্রয়োজনীয়" নয়। লকটি এই কোডটি থ্রেড-নিরাপদ করে তুলবে।

সুতরাং প্রশ্নটি: আপনি কেন প্রথম যুক্ত করবেন if (instance == null)?

কারণটি সম্ভবত কোডের লক করা বিভাগটি অকারণে চালানো এড়ানো নয়। আপনি লকের অভ্যন্তরে কোডটি সম্পাদন করার সময়, অন্য কোনও থ্রেড যা সেই কোডটি কার্যকর করতে চেষ্টা করে তা অবরুদ্ধ করা আছে, যা আপনি যদি অনেক থ্রেড থেকে ঘন ঘন সিঙ্গলটন অ্যাক্সেস করার চেষ্টা করেন তবে আপনার প্রোগ্রামটি ধীর করবে। ভাষা / প্ল্যাটফর্মের উপর নির্ভর করে লকটি নিজে থেকে এড়ানো যেতে পারে যা আপনি এড়াতে চান।

সুতরাং আপনার তালার দরকার আছে কিনা তা দেখার জন্য প্রথম নাল চেকটি সত্যই দ্রুত উপায় হিসাবে যুক্ত করা হয়েছে। আপনার যদি সিঙ্গলটন তৈরি করার প্রয়োজন না হয় তবে আপনি লকটি পুরোপুরি এড়াতে পারবেন।

তবে আপনি কোনওভাবে লক না করে রেফারেন্সটি বাতিল কিনা তা পরীক্ষা করতে পারবেন না, কারণ প্রসেসরের ক্যাশে হওয়ার কারণে, অন্য থ্রেড এটি পরিবর্তন করতে পারে এবং আপনি একটি "বাসি" মান পড়বেন যা আপনাকে অকারণে লকটিতে প্রবেশ করতে পরিচালিত করবে। তবে আপনি একটি লক এড়ানোর চেষ্টা করছেন!

সুতরাং আপনি লক ব্যবহারের প্রয়োজন ছাড়াই সর্বশেষ মানটি নিশ্চিত করে তা নিশ্চিত করতে আপনি সিঙ্গলটনকে অস্থির করে তুলছেন।

আপনার এখনও অভ্যন্তরীণ লকটি প্রয়োজন কারণ অস্থির কেবলমাত্র ভেরিয়েবলের একক অ্যাক্সেসের সময় আপনাকে রক্ষা করে - আপনি লকটি ব্যবহার না করে এটিকে নিরাপদে পরীক্ষা করতে এবং সেট করতে পারবেন না।

এখন, এটি কি আসলে কার্যকর?

আচ্ছা আমি বলব "বেশিরভাগ ক্ষেত্রে, না"।

যদি সিঙ্গেলটন.আইন্সটেন্স লকগুলির কারণে অদক্ষতার কারণ হতে পারে, তবে আপনি কেন এত ঘন ঘন এই ফোন করছেন যে এটি একটি উল্লেখযোগ্য সমস্যা হবে ? সিঙ্গলটনের পুরো বক্তব্যটি কেবলমাত্র একটি, তাই আপনার কোডটি একবারে সিঙ্গলটন রেফারেন্সটি পড়তে এবং ক্যাশে করতে পারে।

কেবলমাত্র এই ক্ষেত্রেটিই ভাবতে পারি যেখানে এই ক্যাচিং সম্ভব হবে না যখন আপনার প্রচুর পরিমাণে থ্রেড থাকবে (যেমন প্রতিটি অনুরোধ প্রক্রিয়া করার জন্য একটি নতুন থ্রেড ব্যবহার করে এমন একটি সার্ভার লক্ষ লক্ষ স্বল্প-চলমান থ্রেড তৈরি করতে পারে) যা একবার সিঙ্গলটন.ইনস্ট্যান্স কল করতে হবে)।

সুতরাং আমি সন্দেহ করি যে ডাবল চেকড লক করা এমন একটি প্রক্রিয়া যা খুব নির্দিষ্ট পারফরম্যান্স-সমালোচনামূলক ক্ষেত্রে সত্যিকারের স্থান পায় এবং তারপরে প্রত্যেকে "এটি করার সঠিক উপায় এটি" ব্যান্ডউইগানকে আসলে কী করে তা ভেবে চিন্তিত না করেই তা দৃmb়ভাবে উচ্চারিত হয়েছে। তারা এটির জন্য ব্যবহার করছে সেই ক্ষেত্রে আসলে এটি প্রয়োজনীয় হবে।

Question 5

ডাবল চেক লক প্যাটার্ন সহ আপনার অস্থির ব্যবহার করা উচিত।

বেশিরভাগ লোকেরা এই নিবন্ধটি প্রমাণ হিসাবে দেখায় যে আপনার অস্থিরতার দরকার নেই: https://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S10

তবে তারা শেষ পর্যন্ত পড়তে ব্যর্থ হয়েছিল: " সতর্কতার একটি চূড়ান্ত শব্দ - আমি বিদ্যমান প্রসেসরের উপর পর্যবেক্ষণ আচরণ থেকে x86 মেমরি মডেলটিতে অনুমান করছি am সুতরাং লো-লক কৌশলগুলিও ভঙ্গুর কারণ হার্ডওয়্যার এবং সংকলকরা সময়ের সাথে সাথে আরও আক্রমণাত্মক হতে পারে । আপনার কোডে এই ভঙ্গুরতার প্রভাব হ্রাস করার জন্য এখানে কিছু কৌশল রয়েছে First প্রথমত, যখনই সম্ভব হয়, কম-লক কৌশলগুলি এড়িয়ে চলুন ((...) অবশেষে, অন্তর্নিহিত গ্যারান্টিগুলির উপর নির্ভর না করে অস্থির ঘোষণাগুলি ব্যবহার করে দুর্বলতম স্মৃতি মডেলটিকে সম্ভব বলে মনে করুন possible "

আপনার যদি আরও দৃinc় বিশ্বাসের প্রয়োজন হয় তবে ইসিএমএ স্পেসে এই নিবন্ধটি পড়ুন অন্যান্য প্ল্যাটফর্মগুলির জন্য ব্যবহার করা হবে: এমএসডিএন.মাইক্রোসফটকম /en-us/magazine/jj863136.aspx

আপনার যদি এই নতুন আর্টিকেলটি আরও পড়ার দৃ need় বিশ্বাসের প্রয়োজন হয় তবে এটি অপরিবর্তনীয় কাজগুলিকে অস্থিরতা ছাড়াই কাজ করা থেকে বিরত রাখতে পারে: এমএসডিএন.ইমিক্রোসফটিও / ম্যাগাজিন /jj883956.aspx

সংক্ষেপে এটি "মুহুর্তের জন্য" আপনার পক্ষে অস্থির ছাড়াই কাজ করে তবে এটি সঠিক কোডটি লেখার এবং অস্থিরতা বা অস্থিরতা / লেখার পদ্ধতি ব্যবহার করার সুযোগ দেবেন না। নিবন্ধগুলি অন্যথায় করার পরামর্শ দেয় কখনও কখনও জেআইটি / সংকলক অনুকূলিতকরণের কিছু সম্ভাব্য ঝুঁকির কথা বাদ দেয় যা আপনার কোডকে প্রভাবিত করতে পারে, পাশাপাশি আমাদের ভবিষ্যতের অপ্টিমাইজেশানগুলি ঘটতে পারে যা আপনার কোডটি ভেঙে দিতে পারে। গত প্রবন্ধে উল্লিখিত অনুমান হিসাবে ইতিমধ্যে অস্থির ছাড়া কাজ করার পূর্ববর্তী অনুমানগুলি এআরএম ধরে রাখতে পারে না।

Question 6

আফাইক (এবং - সাবধানতার সাথে এটি গ্রহণ করুন, আমি প্রচুর পরিমাণে সমবর্তী জিনিস করছি না) না। লকটি আপনাকে একাধিক প্রতিযোগী (থ্রেড) এর মধ্যে সিংক্রোনাইজেশন দেয়।

অন্যদিকে অস্থিরতা আপনার মেশিনকে প্রতিবারের মানটি পুনর্বিবেচনা করতে বলে, যাতে আপনি কোনও ক্যাশেড (এবং ভুল) মান না পড়ে।

Http://msdn.microsoft.com/en-us/library/ms998558.aspx দেখুন এবং নীচের উদ্ধৃতিটি নোট করুন:

এছাড়াও, উদাহরণটি ভেরিয়েবল অ্যাক্সেস করার আগে উদাহরণটি ভেরিয়েবলের অ্যাসাইনমেন্টটি সম্পূর্ণ হয় তা নিশ্চিত করতে ভেরিয়েবলটিকে অস্থায়ী হিসাবে ঘোষণা করা হয়।

অস্থির একটি বিবরণ: http://msdn.microsoft.com/en-us/library/x13ttww7%28VS.71%29.aspx

Question 7

আমি মনে করি যে আমি যা খুঁজছিলাম তা খুঁজে পেয়েছি। বিশদটি এই নিবন্ধে রয়েছে - http://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S10 ।

সংক্ষেপে বলতে গেলে - NET অস্থির পরিবর্তনকারীটির এই পরিস্থিতিতে প্রকৃতপক্ষে প্রয়োজন হয় না। তবে দুর্বল মেমরির মডেলগুলিতে অলসভাবে শুরু করা অবজেক্টের কনস্ট্রাক্টরে তৈরি লেখাগুলি ফিল্ডে লেখার পরে বিলম্ব হতে পারে, সুতরাং অন্যান্য থ্রেডগুলি যদি বিবৃতিতে প্রথমে দুর্নীতিযুক্ত অ-নাল উদাহরণ পড়তে পারে।

Question 8

lockযথেষ্ট। এমএস ল্যাঙ্গুয়েজ স্পেস (3.0.০) নিজেই এই নির্ভুল দৃশ্যের উল্লেখ without8.12-এ করেছে, কোনও উল্লেখ ছাড়াই volatile:

একটি আরও ভাল পদ্ধতির একটি ব্যক্তিগত স্ট্যাটিক অবজেক্ট লক করে স্থিতিশীল ডেটা অ্যাক্সেস সুসংগত করা হয়। উদাহরণ স্বরূপ:
class Cache
{
    private static object synchronizationObject = new object();
    public static void Add(object x) {
        lock (Cache.synchronizationObject) {
          ...
        }
    }
    public static void Remove(object x) {
        lock (Cache.synchronizationObject) {
          ...
        }
    }
}

Question 9

ডাবল চেকড লক সহ অস্থির ব্যবহার সম্পর্কে এটি একটি দুর্দান্ত পোস্ট post

http://tech.puredanger.com/2007/06/15/double-checked-locking/

জাভাতে, যদি উদ্দেশ্যটি কোনও ভেরিয়েবলকে রক্ষা করা হয় তবে এটি যদি অস্থির হিসাবে চিহ্নিত হয় তবে আপনাকে লক করতে হবে না