On 24/10/05, Sandy McArthur <[EMAIL PROTECTED]> wrote:
> On 10/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> > are there any pool developers out there with time to pick this up?
> >
> > otherwise, we could probably do with a volunteer to go through and
> > analyse these issues. anyone fancy taking a crack at this?
> I'm not a pool dev but I'll make some time to implement fixes for the
> problems Mayur Naik found and submit patches.
> While I'm at it would it be desirable to transition to the privately
> head lock idiom to defend against intentionally malicious code? eg to
> defend against:
> synchronized (aPool) {
>  Thread.sleep(Integer.Max_Value);
> }
> by making anything that synchronized on this synchronize on a private field.

+1 If possible, but one cannot always do this.

If a class is conditionally thread-safe, i.e. it needs external
synchronisation - then the appropriate lock object must be made
available to clients. E.g. HashTable needs external synch for its
Iterator [Bloch, Item 52]


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to