On Mon, Dec 1, 2008 at 5:49 PM, Markus Wiederkehr
<[EMAIL PROTECTED]> wrote:
> 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?
yes - so long as the call is outside the synchronized block, the
thread won't escape from scope
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
