This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Too many race conditions.


Andrew Haley writes:
 > David Daney writes:
 > 
 >  > In the thread using a descriptor, there is a window between when it can 
 >  > test if the descriptor is closed and using the descriptor.  Part of the 
 >  > window is in the syscall code in libc and also in the kernel before it 
 >  > tests for a valid descriptor.
 >  > 
 >  > If during this window, a different thread closes the descriptor and then 
 >  > re-uses it (possibly in two threads), the thread using the descriptor 
 >  > instead of an error will operate on the wrong descriptor.
 > 
 > Ah, I see.  I don't see any way around this problem that doesn't
 > involve locking the descriptor in some way: there will always be a
 > window.
 > 
 > But is locking really such a huge deal?  Really fixing the bug can be
 > done with something like this, at least on platforms that support
 > atomic operations:
 > 
 > Index: natFileChannelPosix.cc
 > ===================================================================
 > --- natFileChannelPosix.cc	(revision 124185)
 > +++ natFileChannelPosix.cc	(working copy)
 > @@ -188,7 +188,11 @@
 >    int r = 0;
 >    while (r != 1)
 >      {
 > -      r = ::write (fd, &d, 1);
 > +      {
 > +	int _fd = __sync_val_compare_and_swap (&fd, fd, -1);
 > +	r = ::write (_fd, &d, 1);
 > +	__sync_val_compare_and_swap (&fd, _fd, _fd);

Duh.

	__sync_val_compare_and_swap (&fd, -1, _fd);

... but you get the idea ...

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]