Normally when you look into optimistic locking you also use a library like Hibernate or an other JPA-Implementation with @Version support. Example could read like this: public class Person { private String firstName; private String lastName; private int age; private Color favoriteColor; @Version private Long version; } while obviously there is no point of adding … Read more
In the simple case given, unlocking in the reverse order is not necessary to avoid a deadlock. However, as the code gets more complicated, unlocking in the reverse order helps you maintain proper lock ordering. Consider: A.lock(); B.lock(); Foo(); A.unlock(); Bar(); B.unlock(); If Bar() attempts to reacquire A, you’ve effectively broken your lock ordering. You’re … Read more
Well, this question is way too old but, here is a compact one I figured out, both codes will end up to the same compiled statements (this and the one in the question description): lock (obj1) lock (obj2) { // your code }
Essentially, if your objects are locked only by one thread, the JVM can make an optimization and “bias” that object to that thread in such a way that subsequent atomic operations on the object incurs no synchronization cost. I suppose this is typically geared towards overly conservative code that performs locks on objects without ever … Read more
I happened to be looking at the same problem. GCC works fine with std::mutex under Linux. However, on Windows things seem to be worse. In the <mutex> header file shipped with MinGW GCC 4.7.2 (I believe you are using a MinGW GCC version too), I have found that the mutex class is defined under the … Read more
According to MSDN, SemaphoreSlim.WaitAsync may throw: ObjectDisposedException – If the semaphore has been disposed ArgumentOutOfRangeException – if you choose the overload which accepts an int and it is a negative number (excluding -1) In both cases, the SemaphoreSlim wont acquire the lock, which makes it unnessacery to release it in a finally block. One thing … Read more
As the other answerer noted, the original code is removing the SemaphoreSlim from the ConcurrentDictionary before it releases the semaphore. So, you’ve got too much semaphore churn going on – they’re being removed from the dictionary when they could still be in use (not acquired, but already retrieved from the dictionary). The problem with this … Read more
See the javadoc for Object.wait. in particular “The current thread must own this object’s monitor.” and “[throws] IllegalMonitorStateException – if the current thread is not the owner of the object’s monitor.” That is, you need to synchronize on the object you are going to call wait on. so your code should be: synchronized (available) { … Read more
For this we use the RAII-style construct std::lock_guard. When you use std::mutex m; { // start of some scope std::lock_guard lg(m); // stuff } // end of scope lg will ensure that m will be unlocked no matter what path the scope is left as it is destroyed at scope exit and std::lock_guards destructor will … Read more
The difference is simple: if the locked-on object is in a static field, then all instances of MyClass* will share that lock (i.e. no two objects will be able to lock on that object at the same time). If the field is non-static, then each instance will have its own lock, so only calls of … Read more