C++17-ൽ നിന്ന് std::shared_mutex മനസ്സിലാക്കുന്നു

std::shared_mutex, റൈറ്റ് ഓപ്പറേഷനുകൾക്കുള്ള എക്സ്ക്ലൂസീവ് ആക്സസ് ഉറപ്പാക്കുമ്പോൾ ഒന്നിലധികം ത്രെഡുകളെ ഒരേസമയം പങ്കിട്ട (റീഡ്) ലോക്കുകൾ ഹോൾഡ് ചെയ്യാൻ അനുവദിക്കുന്ന ഒരു സമന്വയ പ്രാകൃതമാണ്. മൂന്നാം കക്ഷി ലൈബ്രറികളിലേക്കോ പ്ലാറ്റ്‌ഫോം നിർദ്ദിഷ്‌ട APIകളിലേക്കോ എത്താതെ തന്നെ റീഡർ-റൈറ്റർ ലോക്കിംഗ് നടപ്പിലാക്കാൻ ഡവലപ്പർമാർക്ക് വൃത്തിയുള്ളതും നിലവാരമുള്ളതുമായ മാർഗ്ഗം നൽകിക്കൊണ്ട് ആധുനിക C++ ലെ ഏറ്റവും സാധാരണമായ കൺകറൻസി വെല്ലുവിളികളിലൊന്ന് ഇത് പരിഹരിക്കുന്നു.

കൃത്യമായി എന്താണ് std::shared_mutex, എന്തുകൊണ്ട് ഇത് C++17-ൽ ചേർത്തു?

C++17-ന് മുമ്പ്, റീഡർ-റൈറ്റർ സെമാൻ്റിക്‌സ് ആവശ്യമുള്ള ഡെവലപ്പർമാർക്ക് POSIX സിസ്റ്റങ്ങളിലെ pthread_rwlock_t അല്ലെങ്കിൽ Windows-ൽ SRWLOCK പോലുള്ള പ്ലാറ്റ്‌ഫോം-നിർദ്ദിഷ്ട പരിഹാരങ്ങളെ ആശ്രയിക്കേണ്ടി വരും, അല്ലെങ്കിൽ അവർ Boost പോലുള്ള മൂന്നാം കക്ഷി ലൈബ്രറികൾ ഉപയോഗിക്കും. C++17 സ്റ്റാൻഡേർഡ് കമ്മിറ്റി ഈ വിടവ് തിരിച്ചറിയുകയും അത് നേരിട്ട് പരിഹരിക്കുന്നതിനായി std::shared_mutex തലക്കെട്ടിൽ അവതരിപ്പിക്കുകയും ചെയ്തു.

കാതലായ ആശയം ലളിതമാണ്: പല യഥാർത്ഥ ലോക പ്രോഗ്രാമുകളിലും, എഴുതിയതിനേക്കാൾ കൂടുതൽ തവണ ഡാറ്റ വായിക്കപ്പെടുന്നു. ഒരു സ്റ്റാൻഡേർഡ് std::mutex എല്ലാ ആക്‌സസ്സുകളും സീരിയലൈസ് ചെയ്യുന്നു — റീഡുകളും ഉൾപ്പെടുത്തി — ഇത് അനാവശ്യ തടസ്സങ്ങൾ സൃഷ്ടിക്കുന്നു. std::shared_mutex രണ്ട് ലോക്കിംഗ് മോഡുകൾ തമ്മിൽ വേർതിരിച്ചുകൊണ്ട് ആ നിയന്ത്രണം ഉയർത്തുന്നു:

• പങ്കിട്ട (വായിച്ച) ലോക്ക് — lock_shared() വഴി നേടിയത്; ഒന്നിലധികം ത്രെഡുകൾക്ക് ഇത് ഒരേസമയം പിടിക്കാൻ കഴിയും, ഇത് ഒരേസമയം വായിക്കുന്നതിന് അനുയോജ്യമാക്കുന്നു.
• എക്‌സ്‌ക്ലൂസീവ് (എഴുതുക) ലോക്ക് — lock() വഴി നേടിയത്; ഒരു സമയം ഒരു ത്രെഡിന് മാത്രമേ ഇത് കൈവശം വയ്ക്കാൻ കഴിയൂ, കൂടാതെ ഇത് ഹോൾഡ് ചെയ്യുമ്പോൾ പങ്കിട്ട ലോക്കുകളൊന്നും അനുവദനീയമല്ല.
• std::shared_lock — നിർമ്മാണത്തിൽ lock_shared() എന്നതിനെയും നാശത്തിൽ unlock_shared() എന്നതിനെയും വിളിക്കുന്ന RAII റാപ്പർ, വിഭവ ചോർച്ച തടയുന്നു.
• std::unique_lock / std::lock_guard — എക്സ്ക്ലൂസീവ് മോഡിൽ ഉപയോഗിക്കുന്നു, എഴുത്ത് പ്രവർത്തനങ്ങൾ പൂർണ്ണമായും പരിരക്ഷിതവും ഒഴിവാക്കൽ-സുരക്ഷിതവുമാണെന്ന് ഉറപ്പാക്കുന്നു.

ഈ ഡ്യുവൽ മോഡ് ഡിസൈൻ std::shared_mutex കാഷെകൾ, കോൺഫിഗറേഷൻ രജിസ്‌ട്രികൾ, വായനകൾ വർക്ക് ലോഡിൽ ആധിപത്യം പുലർത്തുന്ന ഏതൊരു ഡാറ്റാ ഘടനയും പോലുള്ള സാഹചര്യങ്ങൾക്ക് സ്വാഭാവിക ഫിറ്റ് ആക്കുന്നു.

അഭിപ്രായങ്ങൾക്കൊപ്പം യഥാർത്ഥ കോഡിൽ നിങ്ങൾ എങ്ങനെയാണ് std::shared_mutex ഉപയോഗിക്കുന്നത്?

std::shared_mutex ഉപയോഗിക്കുന്ന കോഡിലെ അഭിപ്രായങ്ങൾ പ്രത്യേകിച്ചും വിലപ്പെട്ടതാണ്, കാരണം കൺകറൻസി ലോജിക്ക് യുക്തിസഹമായി ചിന്തിക്കാൻ പ്രയാസമാണ്. ഒരു പ്രത്യേക ലോക്ക് തരം തിരഞ്ഞെടുത്തത് എന്തുകൊണ്ട് എന്ന് നന്നായി സ്ഥാപിച്ചിട്ടുള്ള അഭിപ്രായങ്ങൾ വ്യക്തമാക്കുന്നു, ഇത് ഭാവിയിൽ മെയിൻ്റനർമാർ ആകസ്മികമായി ഡാറ്റ റേസുകൾ അവതരിപ്പിക്കുന്നതിനുള്ള സാധ്യത ഗണ്യമായി കുറയ്ക്കുന്നു. ഒരു സാധാരണ പാറ്റേൺ ഇതാ:

#include 
#ഉൾപ്പെടുത്തുക 
#ഉൾപ്പെടുത്തുക 

ക്ലാസ് കോൺഫിഗ് രജിസ്ട്രി {
    മ്യൂട്ടബിൾ എസ്ടിഡി::പങ്കിട്ട_മ്യൂട്ടക്സ് mtx_; // താഴെയുള്ള മാപ്പ് പരിരക്ഷിക്കുന്നു
    std::unordered_map data_;

പൊതു:
    // റീഡ് പാത്ത്: ഒന്നിലധികം ത്രെഡുകൾ ഇതിനെ ഒരേസമയം വിളിക്കാം
    std::string get(const std::string& key) const {
        std:: shared_lock ലോക്ക് (mtx_); // പങ്കിട്ട ലോക്ക് — ഒരേസമയം വായിക്കുന്നതിന് സുരക്ഷിതം
        ഓട്ടോ ഇറ്റ് = ഡാറ്റ_.കണ്ടെത്തുക(കീ);
        അത് തിരികെ നൽകുക != data_.end() ? അത്->രണ്ടാം : "";
    }

    // റൈറ്റ് പാത്ത്: എക്സ്ക്ലൂസീവ് ആക്സസ് ആവശ്യമാണ്
    അസാധുവായ സെറ്റ് (const std::string&key, const std::string&val) {
        std::unique_lock ലോക്ക്(mtx_); // എക്സ്ക്ലൂസീവ് ലോക്ക് - എല്ലാ വായനക്കാരെയും തടയുന്നു
        ഡാറ്റ_[കീ] = വാൽ;
    }
};

കോഡ് എന്താണ് ചെയ്യുന്നതെന്ന് പുനഃസ്ഥാപിക്കുന്നതിനുപകരം, ഓരോ ലോക്ക് തിരഞ്ഞെടുപ്പിൻ്റെയും പിന്നിലെ ഉദ്ദേശ്യം കമൻ്റുകൾ വിശദീകരിക്കുന്നത് എങ്ങനെയെന്ന് ശ്രദ്ധിക്കുക. ഇതാണ് സുവർണ്ണ നിലവാരം: അഭിപ്രായങ്ങൾ എന്തുകൊണ്ട് എന്നതിന് ഉത്തരം നൽകണം, എന്ത് എന്നല്ല. മ്യൂട്ടക്‌സിലെ മ്യൂട്ടബിൾ കീവേഡ്, ലോക്ക് ചെയ്യാൻ കഴിയുമ്പോൾ തന്നെ get() എന്നതിനെ const പ്രഖ്യാപിക്കാൻ അനുവദിക്കുന്നു, ഇത് പൊതുവായതും ഭാഷാപരമായ പാറ്റേണുമാണ്.

കീ ഇൻസൈറ്റ്: എല്ലായ്‌പ്പോഴും RAII ലോക്ക് റാപ്പറുകൾ ഉപയോഗിക്കുക (std::shared_lock, std::unique_lock) std::shared_mutex — ഒരിക്കലും lock() വിളിക്കരുത് lock() ഒഴിവാക്കലുകളുടെ സാന്നിധ്യത്തിൽ സ്വമേധയാലുള്ള ലോക്കിംഗ് തടസ്സങ്ങളിലേക്കും നിർവചിക്കപ്പെടാത്ത പെരുമാറ്റത്തിലേക്കും ഉറപ്പുള്ള പാതയാണ്.

std::shared_mutex-ൽ പ്രവർത്തിക്കുമ്പോൾ ഉണ്ടാകുന്ന സാധാരണ അപകടങ്ങൾ എന്തൊക്കെയാണ്?

വ്യക്തമായ അഭിപ്രായങ്ങളും നല്ല ഉദ്ദേശങ്ങളും ഉണ്ടെങ്കിലും, std::shared_mutex-ന് പരിചയസമ്പന്നരായ ഡെവലപ്പർമാരെ ട്രിപ്പ് ചെയ്യുന്ന സൂക്ഷ്മമായ കെണികളുണ്ട്. ഏറ്റവും അപകടകരമായത് ലോക്ക് അപ്‌ഗ്രേഡാണ്: പങ്കിട്ട ലോക്ക് ആദ്യം റിലീസ് ചെയ്യാതെ തന്നെ ഒരു എക്‌സ്‌ക്ലൂസീവ് ലോക്കിലേക്ക് അപ്‌ഗ്രേഡ് ചെയ്യുന്നതിന് ബിൽറ്റ്-ഇൻ മാർഗമില്ല. റിലീസ് ചെയ്യാതെ അങ്ങനെ ചെയ്യാൻ ശ്രമിക്കുന്നത് ഒരു തൽക്ഷണ ഡെഡ്‌ലോക്ക് സൃഷ്‌ടിക്കുന്നു, കാരണം ത്രെഡ് ഒരു പങ്കിട്ട ലോക്കിനായി കാത്തിരിക്കുമ്പോൾ അത് കൈവശം വച്ചിരിക്കുന്നതുൾപ്പെടെ, ഏതെങ്കിലും പങ്കിട്ട ലോക്ക് നിലനിൽക്കുന്നിടത്തോളം ഒരിക്കലും അനുവദിക്കാൻ കഴിയില്ല.

തെറ്റായ ഗ്രാനുലാരിറ്റി സംരക്ഷിക്കുന്നതാണ് മറ്റൊരു സാധാരണ തെറ്റ്. ഡെവലപ്പർമാർ ചിലപ്പോൾ വളരെ വിശാലമായി ലോക്ക് ചെയ്യുന്നു, റീഡർ-റൈറ്റർ പാറ്റേണിൻ്റെ ഉദ്ദേശ്യത്തെ പരാജയപ്പെടുത്തുന്നു, അല്ലെങ്കിൽ വളരെ ഇടുങ്ങിയതായി, രണ്ട് വ്യത്യസ്ത ലോക്ക് ഏറ്റെടുക്കലുകൾക്കിടയിൽ മാറ്റമില്ലാത്തവ ലംഘിക്കുന്ന വിൻഡോകൾ ഉപേക്ഷിക്കുന്നു. വേരിയബിൾ ലോക്ക് ചെയ്യപ്പെടുന്നതിനുപകരം, മാറ്റമില്ലാത്തത് സംരക്ഷിക്കപ്പെടുന്നു എന്നതിനെ വിവരിക്കുന്ന കമൻ്റുകൾ, കോഡ് അവലോകന സമയത്ത് കൃത്യതയെക്കുറിച്ച് ന്യായവാദം ചെയ്യാൻ ടീമുകളെ സഹായിക്കുന്നു.

പ്രകടനം നിങ്ങളെ അത്ഭുതപ്പെടുത്തുകയും ചെയ്യും. ധാരാളം എഴുത്തുകാർ ഉള്ള വളരെ തർക്കമുള്ള സിസ്റ്റങ്ങളിൽ, അധിക ബുക്ക് കീപ്പിംഗ് ഓവർഹെഡ് കാരണം, std::shared_mutex യഥാർത്ഥത്തിൽ ഒരു പ്ലെയിൻ std::mutex എന്നതിനേക്കാൾ മോശമായി പ്രവർത്തിച്ചേക്കാം. റീഡർ-റൈറ്റർ ലോക്കിംഗ് ഒരു നെറ്റ് വിജയമാണെന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് എല്ലായ്പ്പോഴും പ്രൊഫൈൽ ചെയ്യുക.

std::shared_mutex, std::mutex, മറ്റ് ഇതരമാർഗങ്ങൾ എന്നിവയുമായി എങ്ങനെ താരതമ്യം ചെയ്യും?

std::mutex ലളിതവും തർക്കം കുറവായിരിക്കുമ്പോൾ വേഗത്തിൽ നേടുന്നതും വായനയും എഴുത്തും ഏകദേശം തുല്യ ആവൃത്തിയിൽ സംഭവിക്കുമ്പോൾ ഉചിതവുമാണ്. std::shared_mutex റൈറ്റുകളെക്കാൾ ഗണ്യമായി വായിക്കുമ്പോൾ തിളങ്ങുന്നു - സ്വിച്ച് പരിഗണിക്കുന്നതിന് മുമ്പ് 10:1 അല്ലെങ്കിൽ അതിലും ഉയർന്ന അനുപാതം ഒരു ന്യായമായ നിയമമാണ്.

C++14 std::shared_timed_mutex അവതരിപ്പിച്ചു, അത് സമയബന്ധിതമായ ശ്രമങ്ങൾക്കായി try_lock_shared_for(), try_lock_shared_until() എന്നിവ ചേർക്കുന്നു. C++17-ൻ്റെ std::shared_mutex ഒരു മെലിഞ്ഞ നിർവ്വഹണത്തിനായി സമയബന്ധിതമായ വേരിയൻ്റുകൾ കുറയ്ക്കുന്നു. പങ്കിട്ട പാതയിൽ നിങ്ങൾക്ക് സമയബന്ധിതമായ ലോക്കിംഗ് ആവശ്യമുണ്ടെങ്കിൽ, std::shared_timed_mutex ലഭ്യമാണ്, രണ്ട് തരങ്ങളും പൂർണ്ണമായും സ്റ്റാൻഡേർഡ് ആണ്.

ലോക്ക്-ഫ്രീ ഇതരമാർഗ്ഗങ്ങൾക്കായി, std::atomic ശ്രദ്ധാപൂർവ്വമായ മെമ്മറി ഓർഡറിംഗുമായി സംയോജിപ്പിച്ചാൽ ചിലപ്പോൾ ലളിതമായ ഫ്ലാഗുകൾക്കോ കൗണ്ടറുകൾക്കോ വേണ്ടി ഒരു mutex പൂർണ്ണമായും മാറ്റിസ്ഥാപിക്കാനാകും, എന്നാൽ സങ്കീർണ്ണമായ ഡാറ്റാ ഘടനകൾക്ക്, std::shared_mutex സ്റ്റാൻഡേർഡ് ലൈബ്രറിയിൽ ഏറ്റവും വായിക്കാവുന്നതും പരിപാലിക്കാവുന്നതുമായ പരിഹാരമായി തുടരുന്നു.

പതിവ് ചോദിക്കുന്ന ചോദ്യങ്ങൾ

std::shared_mutex പട്ടിണിക്ക് കാരണമാകുമോ?

അതെ, അതിന് കഴിയും. പുതിയ ഷെയർ-ലോക്ക് ഹോൾഡർമാർ തുടർച്ചയായി വന്നുകൊണ്ടിരിക്കുകയാണെങ്കിൽ, ഒരു എക്സ്ക്ലൂസീവ് ലോക്ക് അഭ്യർത്ഥന അനിശ്ചിതമായി കാത്തിരിക്കാം - ഒരു ക്ലാസിക് റൈറ്റർ പട്ടിണി പ്രശ്നം. C++ സ്റ്റാൻഡേർഡ് ഒരു പ്രത്യേക ഫെയർനെസ് നയം നിർബന്ധമാക്കുന്നില്ല, അതിനാൽ പെരുമാറ്റം നടപ്പിലാക്കുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. പ്രായോഗികമായി, മിക്ക സ്റ്റാൻഡേർഡ് ലൈബ്രറി നിർവ്വഹണങ്ങളും തീർച്ചപ്പെടുത്താത്ത എക്‌സ്‌ക്ലൂസീവ് ലോക്കുകൾ ക്യൂവിൽ നിൽക്കുമ്പോൾ അവയ്ക്ക് മുൻഗണന നൽകുന്നു, എന്നാൽ ഉൽപ്പാദനത്തിൽ പട്ടിണി ഒരു ആശങ്കയാണെങ്കിൽ നിങ്ങളുടെ നിർദ്ദിഷ്ട ടൂൾചെയിനിനും പ്ലാറ്റ്‌ഫോമിനും വേണ്ടി നിങ്ങൾ ഇത് പരിശോധിക്കണം.

std::condition_variable-നൊപ്പം ഉപയോഗിക്കാൻ std::shared_mutex സുരക്ഷിതമാണോ?

std::condition_variable-ന് ഒരു std::unique_lock ആവശ്യമാണ്, അതിനാൽ ഇത് std::shared_mutex മായി നേരിട്ട് പൊരുത്തപ്പെടുന്നില്ല. ഒരു പങ്കിട്ട മ്യൂട്ടക്സ് കൈവശം വയ്ക്കുമ്പോൾ നിങ്ങൾക്ക് ഒരു വ്യവസ്ഥയിൽ കാത്തിരിക്കണമെങ്കിൽ, std::condition_variable_any ഉപയോഗിക്കുക, std::shared_mutex ഒരു std::shared_lock മായി ജോടിയാക്കിയത് ഉൾപ്പെടെ, ഏത് BasicLockable തരത്തിലും പ്രവർത്തിക്കുന്നു.

ഞാൻ std::shared_mutex ഉപയോഗിക്കുമ്പോഴെല്ലാം കമൻ്റുകൾ ചേർക്കണോ?

കുറഞ്ഞത്, മ്യൂട്ടക്സ് ഏത് ഡാറ്റയാണ് പരിരക്ഷിക്കുന്നതെന്നും അത് പരിപാലിക്കുന്ന മാറ്റങ്ങളെക്കുറിച്ചും വിവരിക്കുന്നതിന് അതിൻ്റെ പ്രഖ്യാപനം കമൻ്റ് ചെയ്യുക. ഓരോ ലോക്ക് സൈറ്റിലും, പങ്കിട്ടതും എക്‌സ്‌ക്ലൂസീവ് ആക്‌സസും എന്തിനാണ് തിരഞ്ഞെടുത്തതെന്ന് വിശദീകരിക്കുന്ന ഒരു ഹ്രസ്വ അഭിപ്രായം കോഡ് അവലോകനം ചെയ്യുന്നവർക്കും ഭാവി പരിപാലിക്കുന്നവർക്കും കാര്യമായ മൂല്യം നൽകുന്നു. പുനർനിർമ്മിക്കുന്നതിനും പരിഹരിക്കുന്നതിനും ഏറ്റവും ബുദ്ധിമുട്ടുള്ള ഒന്നാണ് കൺകറൻസി ബഗുകൾ, അതിനാൽ വ്യക്തമായ, കൃത്യമായ അഭിപ്രായങ്ങളിലെ നിക്ഷേപം പലതവണ ലാഭവിഹിതം നൽകുന്നു.

സങ്കീർണ്ണമായ സിസ്റ്റങ്ങൾ കൈകാര്യം ചെയ്യുന്നത് - സമകാലികമായ C++ കോഡോ അല്ലെങ്കിൽ ഒരു മുഴുവൻ ബിസിനസ് പ്രവർത്തനമോ ആകട്ടെ - ശരിയായ ഉപകരണങ്ങളും വ്യക്തമായ ഘടനയും ആവശ്യപ്പെടുന്നു. Mewayz എന്നത് മാർക്കറ്റിംഗ്, CRM, ഇ-കൊമേഴ്‌സ്, അനലിറ്റിക്‌സ് എന്നിവയിലും മറ്റും ഒരേ വ്യക്തത കൊണ്ടുവരാൻ 138,000-ലധികം ഉപയോക്താക്കൾ വിശ്വസിക്കുന്ന 207-മൊഡ്യൂൾ ബിസിനസ്സ് OS ആണ്, എല്ലാം ഒരു പ്ലാറ്റ്‌ഫോമിൽ പ്രതിമാസം $19 മുതൽ ആരംഭിക്കുന്നു. വിച്ഛേദിക്കപ്പെട്ട ഡസൻ കണക്കിന് ടൂളുകൾ കൈകാര്യം ചെയ്യുന്നത് നിർത്തുക, നന്നായി രൂപകൽപ്പന ചെയ്ത സോഫ്റ്റ്‌വെയറിൻ്റെ കൃത്യതയോടെ നിങ്ങളുടെ ബിസിനസ്സ് പ്രവർത്തിപ്പിക്കാൻ തുടങ്ങുക. app.mewayz.com-ൽ ഇന്ന് Mewayz പരീക്ഷിച്ചുനോക്കൂ കൂടാതെ നിങ്ങളുടെ ടീം പ്രവർത്തിക്കുന്ന രീതിയെ ഒരു ഏകീകൃത സിസ്റ്റം എങ്ങനെ പരിവർത്തനം ചെയ്യുന്നുവെന്ന് കാണുക.