This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: PATCH: remove all traces of java.io.FileDescriptor from java.net
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, java-patches at gcc dot gnu dot org
- Date: Thu, 28 Mar 2002 16:44:16 +1200
- Subject: Re: PATCH: remove all traces of java.io.FileDescriptor from java.net
- References: <Pine.LNX.4.10.10203272318000.6878-100000@mars.deadcafe.org>
Jeff Sturm wrote:
>On Wed, 27 Mar 2002, Bryce McKinlay wrote:
>
>>>Here's my updated patch. Hans convinced me that close/finalize ought to
>>>synchronize access to fnum, I've included that below.
>>>
>>Hmm, why is that? Also I noticed that it is actually synchronizing
>>twice, both in finalize and close?
>>
>
>Finalize and close both access fnum, and will run in different threads. A
>I understand the Java memory model, it is theoretically possible (however
>unlikely) to have the same fd close twice if we don't synchronize.
>
>We'd get the same effect by declaring fnum volatile, if volatile were
>handled correctly.
>
OK, that makes sense, but doesn't only finalize() need to be
synchronized to get the "volatile barrier" behaviour? Or, at least, only
close(). I don't see why we need to synchronize twice!
regards
Bryce.