[concurrency-interest] Reader-writer visibilityinLinkedBlockingQueue

David Holmes davidcholmes at aapt.net.au
Fri Aug 16 01:02:15 EDT 2013


No there is no requirement for writes to become visible "immediately". Only
the happens-before ordering guarantees visibility - if you see a given write
then you must also see writes that happen-before that first write. In
practice writes don't take long to become visible on most architectures -
there is typically a delay until a write buffer drains.

David
  -----Original Message-----
  From: 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 2:50 PM
  To: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Reader-writer
visibilityinLinkedBlockingQueue


  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. 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>
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]On Behalf Of Ashwin
Jayaprakash
      Sent: Friday, 16 August 2013 12:36 PM
      To: 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
before deciding to use your time. I think the answer is evident but just
need a confirmation)


      In the source comment here 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 is not marked volatile
        2.. The dequeue thread always acquires the takeLock. The only time
it acquires, signals and quickly releases the putLock 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!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130816/659015ce/attachment-0001.html>


More information about the Concurrency-interest mailing list