Why don't C++ use lock/unlock directly?
This article introduces the relevant knowledge of "Why C++ should not use lock/unlock directly". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!
CP.20: use RAII and never use lock/unlock directly
Reason (reason)
Avoids nasty errors from unreleased locks.
Avoid serious problems caused by the lock not being released.
Example, bad (negative example)
Mutex mtx
Void do_stuff ()
{
Mtx.lock ()
/ /... Do stuff...
Mtx.unlock ()
}
Sooner or later, someone will forget the mtx.unlock (), place a return in the... Do stuff..., throw an exception, or something.
Sooner or later someone will forget to call mtx.unlock () and put the return statement in the... do stuff.... Position, throw an exception, or do something.
Mutex mtx
Void do_stuff ()
{
Unique_lock lck {mtx}
/ /... Do stuff...
} Enforcement (implementation recommendations)
Tag code that directly calls a lock or unlock member function.
RAII
Resource acquisition, that is, initialization, or RAII, is a C++ programming technology that must bind the life cycle of resources (heap memory, threads, socket, files, mutex, memory space, database links-anything provided by priority supply) to the life cycle of an object before use.
This is the end of the content of "Why C++ should not use lock/unlock directly". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!
