[Spread-users] Question about thread-safety

[Jonathan Stanton]

On Mon, Jun 16, 2003 at 05:38:01PM -0400, John Schultz wrote:
> 
> >>NOTE: if anyone knows how to instruct Unix/Linux systems not to reuse
> >>file descriptor IDs in a process, could you please email me or the list
> >>a good reference (with page #)? Thanks!
> 
> > It is part of the guaranteed semantics of open() that it returns the
> > lowest available file descriptor, so there's definitely no way to do
> > this unless you simply keep it open.
> 
> Doesn't this cause a general race condition in multi-threaded Unix/Linux
> applications that open and close file descriptors in multiple threads?
> 
> The race condition: a thread is about to operate on file descriptor x, but
> just before it does another thread(s) close x and create a new file
> descriptor which is assigned the same value as x.
> 
> To avoid this race condition wouldn't all calls that create and/or close
> file descriptors have to be done in a single thread that ensures no other
> threads are operating on any file descriptors it is about to close? If so,
> that seems like a BAD thing to me.

It sounds like you are asking "Why doesn't the OS interface solve this
synchronization problem for me?" and the answer is that it isn't always
true that you want the OS to solve it for you. 

There are lots of reasons it is like this now: History (64bit counters
on 16 bit machines? in 1978?), size of id (32->64 doubles the memory
cost), usefulness (having all allocated fd's be contiguous numbers makes
it easy to scan through them and be sure you got them all, think about
scanning through all values of a 64bit counter to see which ones are
open).

I agree with multithreaded programs this behaviour requires you to
synchronize fd creation/destruction and not treat fd's as globally
unique 'eternal' ids, but rather globally unique 'at one point in time'
ids. But is this really such a big deal?


> I disagree on practical grounds.  You could use a 64b counter that is only
> incremented to assign file descriptor IDs -- if you flip that bad boy,
> then exit.  Of course, because we are talking about file descriptors, by
> then homo sapiens probably would have already evolved into something else.

As I pointed out above there are some disadvantages of 64b counters, and
some historical baggage. And on theoretical grounds, even though 64b is
big (yes, I agree it is really really big :-)), it is still finite,
while the current scheme only limits to a finite number the 'currently'
allocated fds, rather then limit the number of fds allocated 'over all
time".

Jonathan

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------