Menu
I have a question regarding memory barriers when using a Condition provided by a Lock.
Regarding the example provided in the javadoc for Condition, I have a question about the use of:
int putptr, takeptr, count;
Shouldn't these attributes be declared volatile? As I understand it from the example, a thread might not see the modifications of, e.g., count.
Or is it that, when signal() is called, all modifications made since the lock was acquired are visible to other threads? Much like some code in a synchronized block?
If yes, are the modifications visible when signal() is called, or when unlock() is called on the lock?
Thanks.
Edit: I see in the javadoc of Lock:
All Lock implementations must enforce the same memory synchronization semantics as provided by the built-in monitor lock, as described in section 17.4 of The Java™ Language Specification:
- A successful lock operation has the same memory synchronization effects as a successful Lock action.
- A successful unlock operation has the same memory synchronization effects as a successful Unlock action.
Unsuccessful locking and unlocking operations, and reentrant locking/unlocking operations, do not require any memory synchronization effects.
Do they mean: "A successful lock operation has the same memory synchronization effects as entering a synchronized block", and "A successful unlock operation has the same memory synchronization effects as exiting a synchronized block"?
946
concurrent. locks Description. Interfaces and classes providing a framework for locking and waiting for conditions that is distinct from built-in synchronization and monitors.
In computing, a memory barrier, also known as a membar, memory fence or fence instruction, is a type of barrier instruction that causes a central processing unit (CPU) or compiler to enforce an ordering constraint on memory operations issued before and after the barrier instruction.
You can create a condition variable by calling lock. newCondtion() method. This class provides a method to wait on a condition and notify waiting for threads, much like the Object class' wait and notify method. Here instead of using wait() to wait on a condition, you call await() method.
Concurrency control and locking is the mechanism used by DBMSs for the sharing of data. Atomicity, consistency, and isolation are achieved through concurrency control and locking.
The way you should read into it is, all writes that occur prior to a lock.unlock are visible to all subsequent lock.lock. A thread that is awaiting, when woken up, will essentially do lock.lock. So all writes that occurred since the previous unlock will now be visible.
The signal has no memory semantics, as your latter point states or when unlock() is called on the lock is correct.
Do they mean: "A successful lock operation has the same memory synchronization effects as entering a synchronized block", and "A successful unlock operation has the same memory synchronization effects as exiting a synchronized block"?
Yes, exactly! More specifically the compiler will issue monitorenter and monitorexit byte code instructions.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
