[concurrency-interest] Tree{Map,Set}

David Holmes dholmes at dltech.com.au
Mon Apr 4 21:34:06 EDT 2005

> In my persist() method I am synchronizing on 'head_' (a
> LinkedNode) instance variable in LinkedQueue class. Will this
> cause any dead locks when put(Object) and get() methods are being
> called in different threads?

You won't "deadlock" because you only acquire a single lock and a deadlock
requires at least two locks to be involved.

But your synchronization in persist is not correct. You are attempting to
use synchronization on head_ to gain consistent access to the queue.
Synchronizing on head_ prevents anything from being removed from the queue
while you traverse it, but it doesn't stop something from being added to the
end. When your traversal gets to the tail there is a theoretical possibility
of something going wrong because you don't sync on the same object used for
insertions. Strictly speaking, under the memory model rules you are not
guaranteed to see an inserted node - but worse you may see the node but see
a null value in that node. In practice this is unlikely to occur.

Further, your persist operation is not atomic with respect to the
accompanying put() or take(), so the queue that gets persisted may be
different from what you expect. If you are going to persist the queue after
every modification and lock out all removals during the persist, then you
may as well just synchronized your put() and take() (and offer and poll)
methods and prevent concurrent access in the first placed.

If you think your program is deadlocking then forcing the VM to dump its
internal thread state should show that. (ctrl-\ ?).

Hope this helps.

David Holmes

More information about the Concurrency-interest mailing list