This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
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.