Hello Marcin and Trustin,
On 3/29/07, Marcin Waldowski <[EMAIL PROTECTED]> wrote:
Trustin Lee wrote:
> 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
Hello
I agree with Trustin and I think that we will not have a visiblility
problem with DECODER_LOCK attribute, bacause thread local memory will be
flushed to main memory at the end of synchronized block around
decoder.decode( session, in, decoderOut );
If Trustin is 100% certian that no two threads can execute the
getDecoderLock() method simultaneously for the same IoSession than
there is no problem:
they will both use the same lockObject and memory writes of one thread
will indeed be visible to the other thread.
In that case, I would mention this fact in the javadoc of the
getDecoderLock() function. Another option is to synchronize on the
IoSession in the getDecoderLock function (as I posted before).
Would this degrade performance noticeably, I don't think so ?
However, if they can execute the getDecoderLock() method
simultaneously for the same IoSession, then it is possible that they
use different lock objects.
In that case the Java Memory Model does not guarantee that writes of
one thread are visible by the other, it is absolutely essential that
they lock on the same monitor.
(it is very well explained in chapter 16 of Java Concurrency in Practice)
Maarten
But I don't feel like an expert of java concurrecy. I based only on
following article in subject of visibility:
http://www.javaworld.com/jw-02-2001/jw-0209-double.html
Regards, Marcin
