Code review request, 8013809 deadlock in SSLSocketImpl between between write and close

Xuelei Fan xuelei.fan at oracle.com
Tue Aug 6 02:54:43 UTC 2013


If no objections, I will push the changeset, and request to back the fix.

Thanks,
Xuelei

On 8/2/2013 9:12 AM, Xuelei Fan wrote:
> On 8/2/2013 8:45 AM, Brad Wetmore wrote:
>>
>>
>> On 7/25/2013 2:11 AM, Xuelei Fan wrote:
>>> Hi Brad,
>>>
>>> Are you available to review this fix?
>>>
>>> Webrev: http://cr.openjdk.java.net/~xuelei/8013809/webrev.00/
>>>
>>> No new regression test, hard to reproduce the issue.
>>
>> Your immediate fix looks good, however, IIRC, the reason for having
>> getConnectionState() was to provide synchronized access (and syncing on
>> the SSLSocketImpl object) to the connectionState variable before the
>> Java "volatile" semantics were cleaned up in JDK 1.5.
>>
> I think there is a lot of different of a "volatile" object and a
> synchronized block.  A volatile object is to make sure the change and
> access of the object is synchronized; but synchronized block also make
> sure that the full process of the change is synchronized. For example:
> 
>       synchronized (aLock) {
>          // We want to change the object, but may need
>          // to prepare something before the change, please
>          // don't access this object while we make the preparation.
> 
>          ... // prepare something else.
> 
>          aObject = newvalue;
>       }
> 
>> Now that you've made this change, does it make sense to get rid of
>> getConnectionState(). What do you think?
>>
> I was hesitated to remove the getConnectionState().  When we change the
> value of connectionState, "this" object is locked.  If the value change
> does not completed, other thread cannot access the state.  If we remove
> this synchronization, the behavior would be changed significantly.
> 
> The reason that we can make the change in isClosed() implementation is
> that "APP_CLOSED" is the final state of the life-cycle of connection,
> therefore we don't care too much whether there is another thread is
> doing the closing or not.  It looks like a little tricky.
> 
> Xuelei
> 
>> I hate race conditions!  ;)
>>
>> Brad
>>
>>
> 




More information about the security-dev mailing list