jthread deadlock?

[Alexandre Oliva]

On Mar 27, 1999, Godmar Back <gback at cs.utah.edu> wrote:

>> I don't agree.
>> The wouldlosewakeup mechanism works if interrupts are disabled, if I
>> get it right. This is a piece of code from interrupt():
>> 
>> *********************************************
>> if (intsDisabled()) {
>> ....
>> if (wouldlosewakeup) {
>> write(sigPipe[1], &c, 1);
>> bytesInPipe++; 
>> ....
>> *********************************************
>> 
>> But interrupts are enabled in handleIO just before select. If a signal
>> comes after that but before select it's treated normally, not buffered.

> When thread W is restored, it will enter the select, but at this
> point, there will be a byte to read from the pipe.  This byte was
> written in the SIGIO handler.  Hence, the select won't block and we
> won't deadlock.

But interrupt() would only write to the pipe if intsDisabled(), and
Mihai Surdeanu says SIGIO may be delivered after interrupts are
enabled, but before select() is entered.  And then, if a context
switch takes place before entering select(), another thread may read
all bytes available in sigPipe, so that, when the thread is
re-scheduled, select() would not return immediately because of
sigPipe, although it probably would because of whatever fd that
caused SIGIO to be signalled.

But there's room for problem: if the thread that's going to run
select() stops and another thread creates a threaded file descriptor,
and this file descriptor causes SIGIO to be delivered just when the
select() thread is rescheduled, we won't get any byte in sigPipe,
because interrupts were not disabled, and select() won't return
because the new fd won't be listed in its local copy of the fd_sets.

Unless I'm missing the code that prevents context switches between
blockInts=0 and the select() call in handleIO, we indeed have a
problem.  

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Brasil
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,egcs.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists