উত্সর্গীকৃত থ্রেড লকিং অবজেক্টগুলির জন্য নামকরণ কনভেনশন [বন্ধ]

16

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

4 বছর আগে বন্ধ ছিল ।

একটি অপেক্ষাকৃত ছোট্ট প্রশ্ন, তবে আমি এটি সম্পর্কে অফিসিয়াল ডকুমেন্টেশন বা এমনকি ব্লগের মতামত / আলোচনা সন্ধান করতে সক্ষম হইনি।

সহজ কথায় বলতে গেলে: যখন আমার একটি ব্যক্তিগত অবজেক্ট থাকে যার একমাত্র উদ্দেশ্য ব্যক্তিগত জন্য পরিবেশন করা হয় তখন আমি lockসেই বস্তুর নাম কী রাখি?

class MyClass
{
    private object LockingObject = new object();

    void DoSomething()
    {
        lock(LockingObject)
        {
            //do something
        }
    }
}

আমাদের LockingObjectএখানে নামকরণ করা উচিত ? এছাড়াও কেবল চলকটির নাম নয় তবে লক করার সময় কোডটিতে কী দেখায় তা বিবেচনা করুন।

আমি বিভিন্ন উদাহরণ দেখেছি, তবে আপাতদৃষ্টিতে দৃ solid়ভাবে পরামর্শ দেওয়ার মতো কোনও পরামর্শ নেই:

প্রচুর ব্যবহার SyncRoot(এবং বিভিন্নতা যেমন _syncRoot)।
- কোড নমুনা: lock(SyncRoot) ,lock(_syncRoot)
- এটি ভিবি'র সমতুল্য SyncLockবক্তব্য দ্বারা প্রভাবিত হয়েছে বলে মনে হচ্ছে , SyncRootযে আইকোলিকেশন ক্লাসের কিছু অংশে বিদ্যমান সম্পত্তি এবং কোনও ধরণের সিঙ্করুট ডিজাইন প্যাটার্নের অংশ (যা তাত্ক্ষণিকভাবে একটি খারাপ ধারণা)
- সি # প্রসঙ্গে থাকাকালীন, আমি কোনও ভিবিশ নামকরণ করতে চাই কিনা তা নিশ্চিত নন। আরও খারাপ, ভিবিতে ভেরিয়েবলের নামকরণ কীওয়ার্ডের মতোই। নিশ্চিত না যে এটি বিভ্রান্তির উত্স হবে কিনা।
thisLockএবং lockThisএমএসডিএন নিবন্ধগুলি থেকে: সি # লক স্টেটমেন্ট , ভিবি সিঙ্কলক বিবৃতি
- কোড নমুনা: lock(thisLock) ,lock(lockThis)
- এগুলি উদাহরণের জন্য খাঁটিভাবে নামকরণ করা হয়েছে কিনা তা নিশ্চিত নয়
- অদ্ভুত রকমের যদি আমরা এটি কোনও staticশ্রেণি / পদ্ধতিতে ব্যবহার করি ।
- সম্পাদনা: লকগুলিতে উইকিপিডিয়া নিবন্ধও উদাহরণস্বরূপ এই নামকরণটি ব্যবহার করে
PadLockবিভিন্ন বিবিধ ব্যবহার (বিভিন্ন ধরণের কেসিংয়ের)
- কোড নমুনা: lock(PadLock) ,lock(padlock)
- খারাপ নয়, তবে আমার একমাত্র গরুর মাংস হ'ল এটি আশ্চর্যজনকভাবে কোনও শারীরিক "প্যাডলক" এর চিত্রটিকে আহ্বান করে যা আমি বিমূর্ত থ্রেডিং ধারণার সাথে সংযুক্ত না থাকি ।
এটি কী লক করার ইচ্ছে করছে তার ভিত্তিতে লকটির নামকরণ
- কোড নমুনা: lock(messagesLock) , lock(DictionaryLock),lock(commandQueueLock)
- ভিবি সিঙ্করুট এমএসডিএন পৃষ্ঠার উদাহরণে এটির simpleMessageListএকটি ব্যক্তিগত messagesLockঅবজেক্টের সাথে উদাহরণ রয়েছে
- আমি মনে করি না যে আপনি যে ধরণের লক করছেন তার বিপরীতে লকটির নামকরণ করা ভাল ("ডিকশনারি লক") হিসাবে এটি বাস্তবায়নের বিশদ যা পরিবর্তিত হতে পারে name আপনি যে ধারণাটি বা বস্তুটি লক করছেন তার চারপাশে নামকরণকে আমি পছন্দ করি ("মেসেজস লক" বা "কমান্ডকুইউলক")
- মজার বিষয় হচ্ছে, কোড নমুনায় অনলাইনে বা স্ট্যাকওভারফ্লোতে লক করা অবজেক্টের জন্য আমি এই নামকরণ কনভেনশন খুব কমই দেখতে পাচ্ছি।
(সম্পাদনা) "8.12 দ্য লক স্টেটমেন্ট" বিভাগের অধীনে সি # স্পেসে এই ধরণের উদাহরণ রয়েছে এবং এর নাম দেওয়া হয়েছে synchronizationObject
- কোড নমুনা: lock(SynchronizationObject) ,lock(synchronizationObject)

প্রশ্ন: আপনার মতামত কি সাধারণত নামকরণ সম্পর্কে ব্যক্তিগত লকিং বস্তু?

সাম্প্রতিককালে, আমি তাদের নামকরণ শুরু করেছি ThreadLock(পছন্দসই বিকল্পের মতো 3), তবে আমি নিজেকে এই নামটি নিয়ে প্রশ্ন করছি।

আমি প্রায়শই আমার অ্যাপ্লিকেশন জুড়ে এই লকিং প্যাটার্নটি (উপরে প্রদত্ত কোড নমুনায়) ব্যবহার করছি তাই আমি ভেবেছিলাম তাদের পক্ষে একটি শক্ত নামকরণ কনভেনশন সম্পর্কে আরও পেশাদার মতামত / আলোচনা পাওয়ার জন্য এটি বোধগম্য হতে পারে। ধন্যবাদ!

c# naming multithreading vb.net

— ক্রিস সিনক্লেয়ার
সূত্র

4

অ্যাক্সেস / আপডেট করার জন্য আপনার লকটির প্রয়োজন SomeResourceLockযেখানে এটি ছিল সেখানে ফোন করার অভ্যাসটি আমি গ্রহণ করেছি SomeResource, অর্থাৎ (কোনও থ্রেডের সমস্যাটি ক্ষমা করুন, এটি কেবল একটি চিত্রণ)

public class ProcessDataInQueue
{
    private static Queue<Data> _dataQueue = new Queue<Data>();
    private static object _dataQueueLock = new Object();

    public void AddOneItem(Data itemToAdd)
    {
        lock(_dataQueueLock)
        {
            _dataQueue.Enqueue(itemToAdd);
        }
    }

    public void ProcessOneItem()
    {
        Data itemToProcess = null;
        lock(_dataQueueLock)
        {
            itemToProcess = _dataQueue.Dequeue();
        }
        // ... process itemToProcess
    }
}

আমি ক্লাস করার পরে এই অভ্যাসটি নিয়ে এসেছি যেখানে বিভিন্ন সংস্থার জন্য আমার একাধিক লক থাকতে পারে, তাই আমি লকিং অবজেক্টটির নাম রাখি এটি কোন সংস্থানগুলিতে অ্যাক্সেস অ্যাক্সেস লক করছে তার ভিত্তিতে। কখনও কখনও কোনও বস্তু একাধিক সংস্থানকে লক করে রাখে সেই ক্ষেত্রে আমি নামগুলি কোনও উপায়ে শ্রদ্ধা করার চেষ্টা করতাম, তাই পাঠক জানেন যে "সেই স্বতন্ত্র সংস্থানগুলির জন্য অন্যান্য লকগুলিও এই লকটির সাথে যুক্ত থাকবে"।

— জিমি হোফা
সূত্র

2

আমি মনে করি এটি বিভ্রান্তিকর, কারণ SynchronizationContextএটি বেশ আলাদা।

— এসভিক

1

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

— জিমি হোফা

6

আমি সাধারণত এটি ডাকি locker, তবে এটি ব্যক্তিগত হওয়ার কারণে, আমি বিশ্বাস করি এটি কিছুটা গুরুত্বহীন বাস্তবায়ন বিশদ। থাম্বের প্রথম নিয়ম, আপনার দলের / সংস্থার মান ব্যবহার করুন। যদি একটি না থাকে তবে ভাল, দয়া করে একটি তৈরি করুন এবং এটি ব্যবহার করুন, তবে এটি তৈরিতে, জিনিসগুলি সহজ রাখুন। আপনার ক্লাসে যদি একটি একক লকিং অবজেক্ট থাকে তবে এটি কল করা fooযথেষ্ট। আপনার যদি অনেকগুলি থাকে তবে ব্যবসায়ের একটি ভাল ক্রমটি সম্ভবত শ্রেণীর নকশাকে আবার অনেকগুলি বিভিন্ন জিনিস করছে কিনা তা দেখার জন্য প্রথমে এটি পুনর্বিবেচনা করতে পারে। তবে, যদি তা না হয় তবে নামটি গুরুত্বপূর্ণ হয়ে ওঠে, যেমন সম্পূর্ণরূপে স্বীকৃত উদাহরণটিতে:

public sealed class CustomerOrders
{
    private readonly object customerLocker = new object();

    private readonly object orderLocker = new object();

    public IEnumerable<Customer> Customers
    {
        get
        {
            lock (this.cutomerLocker)
            lock (this.orderLocker)
            {
                // stuff...
            }
        }

        set
        {
            lock (this.cutomerLocker)
            lock (this.orderLocker)
            {
                // other stuff...
            }
        }
    }

    public IEnumerable<Order> Orders
    {
        get
        {
            lock (this.orderLocker)
            {
                // stuff...
            }
        }

        set
        {
            lock (this.cutomerLocker)
            {
                // different stuff...
            }
        }
    }
}

— জেসি সি স্লিকার
সূত্র

2

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

— ক্রিস সিনক্লেয়ার

2

আমি সবসময় lck_ ব্যবহার করতাম। যদি আপনি ctrl + f 'lck' করেন তবে কেবলমাত্র লকগুলি খুঁজে পাওয়া উচিত যখন 'লক' এছাড়াও 'ঘড়ি'র মতো জিনিসগুলি খুঁজে পেতে পারে।

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

— উল্টা লামা
সূত্র

আমি সংক্ষিপ্ত নামগুলির আগ্রহী নই। একদিকে সমস্ত ব্যবহারের সন্ধান করার জন্য একটি অনন্য (ইশ) নামকরণের স্টাইল থাকা বোধগম্য। অন্যদিকে, এবং সম্ভবত আমি ভাগ্যবান হয়েছি, আমার কাছে তালা খুঁজে পাওয়ার দরকার নেই; আমি ভাবছি যদি আমাকে "লক (") সন্ধান করতে হয় তবে খুব সহজেই উপেক্ষা করার জন্য কয়েকটি যথেষ্ট মিথ্যা-পজিটিভ সহ আমার ভাল ফলাফল হতে পারে

— ক্রিস সিনক্লেয়ার