On Mon, Dec 1, 2008 at 2:49 PM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 12:56 PM, Markus Wiederkehr
> <[EMAIL PROTECTED]> 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()) {
storage.delete();
}
}
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?
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
