mutex | 易学教程

Assignment via copy-and-swap vs two locks

阅读更多关于 Assignment via copy-and-swap vs two locks

问题 Borrowing Howard Hinnant's example and modifying it to use copy-and-swap, is this op= thread-safe? struct A { A() = default; A(A const &x); // Assume implements correct locking and copying. A& operator=(A x) { std::lock_guard<std::mutex> lock_data (_mut); using std::swap; swap(_data, x._data); return *this; } private: mutable std::mutex _mut; std::vector<double> _data; }; I believe this thread-safe (remember op='s parameter is passed by value), and the only problem I can find is the one swept

Releasing a Mutex

阅读更多关于 Releasing a Mutex

问题 I have a web application that needs to utilise an application cache to store data (due to the high overhead of obtaining that data ona request by request basis). See previous post at https://stackoverflow.com/a/16961962/236860 This approach seems to work well, but I am seeing the following occasional errors in the web site's error: System.ApplicationException: Object synchronization method was called from an unsynchronized block of code. at System.Threading.Mutex.ReleaseMutex() at

Cross-platform and cross-process atomic int writes on file

阅读更多关于 Cross-platform and cross-process atomic int writes on file

I'm writing an application that will have to be able to handle many concurrent accesses to it, either by threads as by processes. So no mutex'es or locks should be applied to this. To make the use of locks go down to a minimum, I'm designing for the file to be "append-only", so all data is first appended to disk, and then the address pointing to the info it has updated, is changed to refer to the new one. So I will need to implement a small lock system only to change this one int so it refers to the new address. How is the best way to do it? I was thinking about maybe putting a flag before the

Threads and simple Dead lock cure

阅读更多关于 Threads and simple Dead lock cure

问题 When dealing with threads (specifically in C++) using mutex locks and semaphores is there a simple rule of thumb to avoid Dead Locks and have nice clean Synchronization? 回答1: A good simple rule of thumb is to always obtain your locks in a consistent predictable order from everywhere in your application. For example, if your resources have names, always lock them in alphabetical order. If they have numeric ids, always lock from lowest to highest. The exact order or criteria is arbitrary. The

named system mutex not recognized

阅读更多关于 named system mutex not recognized

I am trying named system mutex approach to synchronize two processes- a c# windows service a desktop c# app When the mutex is created, process that didn't create the mutex doesn't seem to detect the existing mutex. Below in more detail: Windows service is responsible for creating the mutex(No prefixes-Global/Local etc. Just a normal named system mutex) as follows: Mutex myMutex= null; try { myMutex= Mutex.OpenExisting(myMutexName); } catch (WaitHandleCannotBeOpenedException x) { //doesn't exist. try { this.GetLogger().Info("Create Mutex"); bool createdNew = false; new Mutex(false, myMutexName,

How to find that Mutex in C# is acquired?

阅读更多关于 How to find that Mutex in C# is acquired?

问题 How can I find from mutex handle in C# that a mutex is acquired? When mutex.WaitOne(timeout) timeouts, it returns false . However, how can I find that from the mutex handle? (Maybe using p/invoke.) UPDATE : public class InterProcessLock : IDisposable { readonly Mutex mutex; public bool IsAcquired { get; private set; } public InterProcessLock(string name, TimeSpan timeout) { bool created; var security = new MutexSecurity(); security.AddAccessRule(new MutexAccessRule(new SecurityIdentifier

Semaphores and Mutex for Thread and Process Synchronization

阅读更多关于 Semaphores and Mutex for Thread and Process Synchronization

问题 I am confused with the usage of semaphores and mutexes at thread and process level. Can we use semphores and mutexes for both thread and process synchronization, or do we have different semaphores and mutexes both at thread and process level? My question is with reference to the POSIX API's. 回答1: The answer to both questions is yes. You can create both mutexes and semaphores as either process-shared or not. So you can use them as interprocess or interthread synchronization objects, but you

Boost named_mutex and remove() command

阅读更多关于 Boost named_mutex and remove() command

I have a class which can be created by multiple threads. But at one function the code needs to be protected, so I decided to use the boost interprocess mutex. Every class creates or opens the same Mutex in it's constructor: MyClass::MyClass() { boost::interprocess::named_mutex m_Lock( boost::interprocess::open_or_create, "myLock" ); } So now there comes the point where the critical code part is called: int MyClass::MyFunction() { boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock( m_Lock, boost::interprocess::try_to_lock); if(!lock) { return -1; } // else do some stuff

When or why should I use a Mutex over an RwLock?

阅读更多关于 When or why should I use a Mutex over an RwLock?

When I read the documentations of Mutex and RwLock , the difference I see is the following: Mutex can have only one reader or writer at a time, RwLock can have one writer or multiple reader at a time. When you put it that way, RwLock seems always better (less limited) than Mutex , why would I use it, then? Sometimes it is better to use a Mutex over an RwLock in Rust: RwLock<T> needs more bounds for T to be thread-safe: Mutex requires T: Send to be Sync , RwLock requires T to be Send and Sync to be itself Sync . In other words, Mutex is the only wrapper that can make a T syncable. I found a

“Could not find a part of the path” error while creating Mutex

阅读更多关于 “Could not find a part of the path” error while creating Mutex

I'm baffled by this, can someone tell me why, when I call: using (Mutex mtx = new Mutex(false, strId)) { } I get this exception: Could not find a part of the path. If strId is set to something like localhost\SQLEXPRESS-MyName-2 ? From the docs : On a server that is running Terminal Services, a named system mutex can have two levels of visibility. If its name begins with the prefix "Global\", the mutex is visible in all terminal server sessions. If its name begins with the prefix "Local\", the mutex is visible only in the terminal server session where it was created. In that case, a separate