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 Mon, 01 Dec 2008 17:49:37 GMT
On Mon, Dec 1, 2008 at 2:49 PM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> On Mon, Dec 1, 2008 at 12:56 PM, Markus Wiederkehr
> <markus.wiederkehr@gmail.com> wrote:
>> The same happens with java.util.Set for example. Interface Set itself
>> is not synchronized but there might be implementations that are.
>> Collections.synchronizedSet() returns a wrapper that does the
>> synchronizing. This is very similar to what I have done with
>> MultiReferenceStorage.
> the synchronized thread escapes from the scope controlled by the
> library through the call. if this can be avoided, it should be since
> it open up potential concurrency issues in code that the library does
> not control. synchronizing just the reference counting code (as below)
> would prevent this possibility.

Do I understand correctly that something like this would be okay?

    public void delete() {
        if (decrementCounter()) {

    private synchronized boolean decrementCounter() {
        return --referenceCounter == 0;

Because although "this" is used as monitor the object is no longer
locked when storage.delete() gets invoked and the thread escapes from
the scope controlled by mime4j?


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

View raw message