[concurrency-interest] Reader-writer visibility inLinkedBlockingQueue

Oleksandr Otenko oleksandr.otenko at oracle.com
Tue Aug 20 10:35:25 EDT 2013

When someone talks about "visible immediately", we need to ask them what 
they mean by "immediately". In particular, how would a external observer 
know that something became visible "not immediately".

You will quickly see that the external observer can only make judgements 
about the order of some events with respect to other events. If 
observing arrival of event A implies arrival of event B can be observed, 
ie A implies B, then you have B happens before A. This is pretty much 
all the external observer can figure out. But this is enough to reason 
about the state of the system.


On 16/08/2013 05:49, Ashwin Jayaprakash wrote:
> Thanks. Just another followup question.
> Can you confirm if this is correct -  a volatile write or atomic 
> dec/inc *becomes visible immediately* to other threads... even when it 
> is done inside a lock-unlock/synchronized block and the *writer thread 
> has not yet exited* the block called lock.unlock(). Like the code we 
> are talking about 
> <http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/util/concurrent/LinkedBlockingQueue.java#456>. 
> Ex: If a writer were to write to volatile or atomic.xx  and then sleep 
> while still holding the lock.. the readers should be able to read the 
> volatile immediately.
> Just making sure because these combination cases are not spelled out 
> anywhere... at least I couldn't find it.
> Thanks again.
> On Thu, Aug 15, 2013 at 7:50 PM, David Holmes 
> <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>> wrote:
>     It is #2 - that is what the "and then reading n = count.get();"
>     refers to.
>     David
>         -----Original Message-----
>         *From:* concurrency-interest-bounces at cs.oswego.edu
>         <mailto:concurrency-interest-bounces at cs.oswego.edu>
>         [mailto:concurrency-interest-bounces at cs.oswego.edu
>         <mailto:concurrency-interest-bounces at cs.oswego.edu>]*On Behalf
>         Of *Ashwin Jayaprakash
>         *Sent:* Friday, 16 August 2013 12:36 PM
>         *To:* concurrency-interest at cs.oswego.edu
>         <mailto:concurrency-interest at cs.oswego.edu>
>         *Subject:* [concurrency-interest] Reader-writer visibility
>         inLinkedBlockingQueue
>         Hi, I have a (naive) question about the JDK 7+
>         LinkedBlockingQueue implementation.
>         (I don't think this question has been asked before. I did
>         search here
>         <http://markmail.org/search/?q=concurrency%20interest%20linkedblockingqueue#query:concurrency%20interest%20linkedblockingqueue+page:15+mid:ocig5f7ry2j5emhl+state:results>
>         before deciding to use your time. I think the answer is
>         evident but just need a confirmation)
>         In the source comment here
>         <http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/util/concurrent/LinkedBlockingQueue.java#97>
>         it says:
>             Visibility between writers and readers is provided as follows:
>             Whenever an element is enqueued, the putLock is acquired and
>             count updated.  A subsequent reader guarantees visibility
>             to the
>             enqueued Node by either acquiring the putLock (via fullyLock)
>             or by acquiring the takeLock, and then reading n =
>             count.get();
>             this gives visibility to the first n items.
>         My understanding of the code:
>          1. I noticed that the Node.next
>             <http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/util/concurrent/LinkedBlockingQueue.java#120>is
>             not marked volatile
>          2. The dequeue thread always acquires the takeLock. The only
>             time it acquires, signals and quickly releases the putLock
>             <http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/util/concurrent/LinkedBlockingQueue.java#181>
>             is when the queue has room for just 1 more item before
>             becoming full again
>          3. The enqueue thread does the opposite of the dequeue
>          4. So, except for the edge cases (recently full/recently
>             empty) where the reader and writer acquire and notify each
>             other, how does the enqueue of a new node (Node.next)
>             become visible to the dequeue?
>         Pardon my ignorance but does this mean that:
>          1. 2 threads that acquire 2 independent locks are enough to
>             make the "next" pointer visible?
>          2. Or is it the AtomicInteger's count.inc/dec that is
>             providing the desired memory effect? *I think this is it,
>             but I'm seeking clarification*
>         Thanks!
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130820/ca726fd9/attachment.html>

More information about the Concurrency-interest mailing list