Hi Maarten,
On 3/29/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
On 3/28/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> Trustin,
>
> I think there is theoretically still a chance that two threads
> synchronize on different lock object for the same session:
>
> + private Object getDecoderLock( IoSession session )
> + {
> + Object lock = session.getAttribute( DECODER_LOCK );
> + if( lock == null )
> + {
> + lock = new Object();
> + session.setAttribute( DECODER_LOCK, lock );
> + }
> +
> + return lock;
> + }
>
> thread A calls session.getAttribute( DECODER_LOCK ) and gets null
> thread B calls session.getAttribute( DECODER_LOCK ) and gets null
> thread A creates a new lock object lockA and stores it in the session
> thread B creates a new lock object lockB and stores it in the session
> thread A locks on lockA and enters decoder.decode
> thread B locks on lockB and also enters decoder.decode
>
> I guess you can't get around locking on the IoSession instance itself ?
ExecutorFilter ensures that two threads don't handle the same session.
So I think the scenario you gave won't happen. But, will we still
have a visibility problem with getDecoderLock() method in this case?
I thought both synchronized HashMap (for 1.0) and ConcurrentHashMap
(for 1.1+) takes care of the visibility problem. WDYT?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
