james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Wiederkehr" <markus.wiederk...@gmail.com>
Subject Re: [mime4j] MultiReferenceStorage Locking
Date Sun, 30 Nov 2008 23:07:40 GMT
On Sun, Nov 30, 2008 at 11:59 PM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> http://svn.apache.org/repos/asf/james/mime4j/trunk/src/main/java/org/apache/james/mime4j/message/storage/MultiReferenceStorage.java
> uses method based synchronization to protect the reference counting
> variable. i wonder whether this is the best approach. (i tend to
> prefer explicit monitors that cannot leak for defensive reasons.)
> in particular
>    public synchronized void delete() {
>        if (referenceCounter == 0)
>            return;
>        referenceCounter--;
>        if (referenceCounter == 0) {
>            storage.delete();
>        }
>    }
> 1. storage is an interface and so storage.delete() represents a leak
> of the thread of execution. i wonder whether it is possible for
> competing storage deletes to produce a deadlock.
> 2. storage.delete() may be a slow operation. the locking appears to be
> protecting only the reference counting. if so then the delete may not
> need to be synchronized,
> it might be possible to avoid explicit synchronization by using
> AtomicInteger instead
> opinions?

Robert, thank you very much for committing my patches so fast.

Regarding the problem with the interface and the leak you describe, I
think I have to read up on that one..

But for delete() possibly being a slow operation, how about using
internal synchronization instead? I mean determine if the storage has
to be deleted in a "synchronized this" block and do the actual
deletion outside of the block..


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message