users@grizzly.java.net

Re: non-blocking connect etc

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Fri, 03 Oct 2008 17:28:38 +0200

>>> No, the issue which I'm wondering about is that threadB might not
>>> see
>>> the new instance of CountDownLatch and get null when it tries to
>>> read
>>> the isConnectedLatch field at line 597, since lack of
>>> synchronization.
>> But threadB could call the finishConnect method only after we set the
>> OP_CONNECT interest in threadA. And we set that interest after
>> CountDownLatch initialization.
> True, but due to lack of sync-ing, you cannot reason about the order
> of which the JVM will make data visible to other threads.
>
> I'm pointing to what is explained here for example:
> http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering
> (or on other pages if you google for 'reoder java memory model'
>
> I might be wrong, but the code in TCPConnectorHandler doesn't
> look safe at first glance. Maybe there is some hidden mecanism to
> ensure visibility which I don't see. That's why I'm asking.

Oh, now got the point :)
You're right, there is no any synchronization on latch. Can you pls.
file an issue?

Thank you.

WBR,
Alexey.


>
>
> Thanks
> Sebastian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>