On Fri, May 26, 2017 at 12:10 PM, Sharath Gururaj <e2718...@gmail.com> wrote:
> Thanks Nitsan and Dmitry for the clear explanation of #2
> I understand it now.
>
> However, In the case of concurrent queues,
> I'm not sure if we should interpret the offer() semantics of java in such a
> strict way. (returns false iff queue is full)
> Because in a concurrent situation, the very question "is the queue full?"
> loses meaning
>
> Even when we return false from offer(), by the time we detect the false
> return, other consumers can race and make the queue not full.
> There is no way to enforce a strict offer() behaviour. Maybe relaxed{Offer,
> Poll} methods should be the default {Offer, Poll} methodI don't know semantics Java interfaces impose, but there cases like the one you described above, but there are also other cases where the queue is provably not-full yet Offer fails. Consider we have a queue with capacity 2. We insert 2 elements initially. Then start 2 threads. Each thread first removes 1 element and then inserts 1 element. Under any interleaving of operations in these threads, the queue is never full during insertion. Yet insertion can fail with the original implementation of the queue. Non-linearilizability can be very confusing. -- --- You received this message because you are subscribed to the Google Groups "Scalable Synchronization Algorithms" group. To unsubscribe from this group and stop receiving emails from it, send an email to lock-free+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/lock-free/CAEeQi3uRBbPkOeFPUrc91hiRQvUgUigC4g7CGgaGqvDNbR%2Bn%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
