Разуменне std::shared_mutex з C++17

std::shared_mutex, уведзены ў C++17, з'яўляецца прымітывам сінхранізацыі, які дазваляе некалькім патокам адначасова ўтрымліваць агульныя блакіроўкі (чытанне), забяспечваючы эксклюзіўны доступ для аперацый запісу. Ён вырашае адну з самых распаўсюджаных праблем паралельнага выканання ў сучасным C++, даючы распрацоўнікам чысты, стандартны спосаб рэалізаваць блакіроўку чытання і запісу без выкарыстання старонніх бібліятэк або спецыфічных API для платформы.

Што такое std::shared_mutex і чаму ён быў дададзены ў C++17?

Да з'яўлення C++17 распрацоўшчыкам, якім патрэбна была семантыка чытання і запісу, даводзілася разлічваць на спецыфічныя для платформы рашэнні, такія як pthread_rwlock_t у сістэмах POSIX або SRWLOCK у Windows, або яны выкарыстоўвалі староннія бібліятэкі, такія як Boost. Камітэт па стандартах C++17 прызнаў гэты прабел і ўвёў std::shared_mutex у загаловак , каб ліквідаваць яго непасрэдна.

Асноўная ідэя простая: у многіх рэальных праграмах дадзеныя чытаюцца значна часцей, чым запісваюцца. Стандартны std::mutex серыялізуе ўвесь доступ, уключаючы чытанне, што стварае непатрэбныя вузкія месцы. std::shared_mutex здымае гэтае абмежаванне, адрозніваючы два рэжымы блакіроўкі:

• Агульная блакіроўка (чытанне) — атрымана праз lock_shared(); некалькі патокаў могуць захоўваць гэта адначасова, што робіць яго ідэальным для адначасовага чытання.
• Эксклюзіўная блакіроўка (запіс) — атрымліваецца праз lock(); толькі адзін паток можа ўтрымліваць гэта адначасова, і ніякія агульныя блакіроўкі не дапускаюцца, пакуль ён утрымліваецца.
• std::shared_lock — абалонка RAII, якая выклікае lock_shared() пры будаўніцтве і unlock_shared() пры знішчэнні, прадухіляючы ўцечку рэсурсаў.
• std::unique_lock / std::lock_guard — выкарыстоўваецца ў эксклюзіўным рэжыме, гарантуючы, што аперацыі запісу цалкам абаронены і абаронены ад выключэнняў.

Гэты двухрэжымны дызайн робіць std::shared_mutex натуральным варыянтам для такіх сцэнарыяў, як кэшы, рэестры канфігурацыі і любыя структуры даных, дзе чытанне дамінуе над працоўнай нагрузкай.

Як вы выкарыстоўваеце std::shared_mutex у рэальным кодзе з каментарамі?

Каментарыі ў кодзе, які выкарыстоўвае std::shared_mutex, асабліва каштоўныя, таму што логіку паралелізму, як вядома, цяжка разважаць. Добра размешчаныя каментарыі ўдакладняюць, чаму быў абраны пэўны тып блакіроўкі, што рэзка зніжае рызыку таго, што будучыя суправаджальнікі выпадкова ўвядуць гонку даных. Вось тыповы шаблон:

#include 
#include 
#include <радок>

клас ConfigRegistry {
    зменлівы std::shared_mutex mtx_; // абараняе карту ніжэй
    std::unordered_map data_;

грамадскасць:
    // Шлях чытання: некалькі патокаў могуць выклікаць гэта адначасова
    std::string get(const std::string& key) const {
        std::shared_lock lock(mtx_); // агульная блакіроўка — бяспечна для адначасовага чытання
        auto it = data_.find(ключ);
        вярнуць яго!= data_.end()? it->second : "";
    }

    // Шлях запісу: патрабуецца эксклюзіўны доступ
    void set(const std::string& key, const std::string& val) {
        std::unique_lock lock(mtx_); // эксклюзіўная блакіроўка — блакуе ўсіх чытачоў
        дадзеныя_[ключ] = значэнне;
    }
};

Звярніце ўвагу, як каментарыі тлумачаць намер кожнага выбару блакіроўкі, а не проста пераказваюць, што робіць код. Гэта залаты стандарт: каментарыі павінны адказваць на чаму, а не на што. Ключавое слова mutable у м'ютэксе дазваляе аб'яўляць get() const, захоўваючы магчымасць блакіроўкі, што з'яўляецца агульным ідыяматычным шаблонам.

Асноўная інфармацыя: заўсёды выкарыстоўвайце абгорткі блакіровак RAII (std::shared_lock, std::unique_lock) з std::shared_mutex — ніколі не выклікайце lock() і unlock() уручную. Ручная блакіроўка пры наяўнасці выключэнняў - гэта гарантаваны шлях да тупіковых блакіровак і нявызначаных паводзін.

Якія распаўсюджаныя падводныя камяні пры працы з 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() для спробаў па часе. std::shared_mutex C++17 адмаўляецца ад прымеркаваных да часу варыянтаў для больш эканомнай рэалізацыі. Калі вам патрэбна блакіроўка па часе на агульным шляху, std::shared_timed_mutex застаецца даступным, і абодва тыпы цалкам стандартныя.

Для альтэрнатыў без блакіроўкі std::atomic у спалучэнні з дбайным упарадкаваннем памяці можа часам цалкам замяніць м'ютэкс для простых сцягоў або лічыльнікаў, але для складаных структур даных std::shared_mutex застаецца найбольш зручным для чытання і абслугоўваннем рашэннем у стандартнай бібліятэцы.

Часта задаюць пытанні

Ці можа std::shared_mutex выклікаць голад?

Так, можа. Калі пастаянна паступаюць новыя ўладальнікі агульных блакіровак, асоба, якая запытвае эксклюзіўную блакіроўку, можа чакаць бясконца — гэта класічная праблема галадання пісьменнікаў. Стандарт C++ не патрабуе пэўнай палітыкі справядлівасці, таму паводзіны залежаць ад рэалізацыі. На практыцы большасць стандартных рэалізацый бібліятэк аддае прыярытэт незавершаным эксклюзіўным блакіроўкам, калі яны ставяцца ў чаргу, але вы павінны праверыць гэта для вашай канкрэтнай ланцужкі інструментаў і платформы, калі галаданне выклікае заклапочанасць у вытворчасці.

Ці бяспечна выкарыстоўваць std::shared_mutex з std::condition_variable?

std::condition_variable патрабуе std::unique_lock, таму ён не сумяшчальны непасрэдна з std::shared_mutex. Калі вам трэба чакаць выканання ўмовы, утрымліваючы агульны м'ютэкс, выкарыстоўвайце std::condition_variable_any, які працуе з любым тыпам BasicLockable, уключаючы std::shared_mutex у пары з std::shared_lock.

Ці варта дадаваць каментары кожны раз, калі я выкарыстоўваю std::shared_mutex?

Як мінімум, пракаментуйце дэкларацыю м'ютэкса, каб апісаць, якія даныя ён абараняе і інварыянты, якія падтрымлівае. На кожным сайце блакіроўкі кароткі каментарый, які тлумачыць, чаму быў абраны агульны доступ, а не эксклюзіўны, дадае значную каштоўнасць для рэцэнзентаў кода і будучых суправаджэння. Памылкі паралелізму з'яўляюцца аднымі з самых складаных для прайгравання і выпраўлення, таму інвестыцыі ў ясныя, дакладныя каментарыі акупляюцца шматразова.

Кіраванне складанымі сістэмамі — адначасовым кодам C++ або цэлай бізнес-аперацыяй — патрабуе правільных інструментаў і выразнай структуры. Mewayz - гэта 207-модульная бізнес-АС, якой давяраюць больш за 138 000 карыстальнікаў, якая ўносіць тую ж яснасць у маркетынг, CRM, электронную камерцыю, аналітыку і многае іншае на адной платформе, пачынаючы з усяго 19 долараў у месяц. Спыніце жангліраваць дзесяткамі адключаных інструментаў і пачніце весці свой бізнес з дакладнасцю добра распрацаванага праграмнага забеспячэння. Паспрабуйце Mewayz сёння на app.mewayz.com і паглядзіце, як уніфікаваная сістэма змяняе спосаб працы вашай каманды.