Xref: utzoo comp.unix.xenix:3995 comp.unix.wizards:12855
Path: utzoo!attcan!uunet!atina!mrecvax!tron
From: tron@mrecvax.UUCP (Carlos Mendioroz)
Newsgroups: comp.unix.xenix,comp.unix.wizards
Subject: wakeup() race condition. (theory)
Keywords: wakeup sleep spl
Message-ID: <455@mrecvax.UUCP>
Date: 24 Nov 88 18:00:16 GMT
Reply-To: tron@mrecvax.UUCP (Carlos Mendioroz)
Organization: M.R.E. y C. Bs. As. Argentina
Lines: 32


A few days ago, I posted an article describing a problem
with a driver that didn't return from a sleep(), though
the call to wakeup was performed.

The process remained in a curious state. It was reported by
ps as runnable (no sleep chan), but the run list pointer
was 0. It also didn't respond to any signal.

A point to note is that the driver's interrupt routine 
priority is 7, and that this routine is calling wakeup()
to awaken the sleeping process.

Theory:
Sleep & wakeup both call spl6() to ensure secure access to
the process queues, (Well, this is not theory, the calls are
there...) and it is possible for the driver's device to 
interrupt as a wakeup() is running, isn't it ?

As this driver (as SCO xenix serial driver) is running with
prio 7, it's not blocked by spl6() and then it may interfere
with the running wakeup by, say, runnig another wakeup.

Solution: (?)
Not to call any wakeup at prio 7, that is, put every driver
interrupt routine that calls wakeup at prio 6 or below.

I would be glad to hear some guru opinion on the topic.
-- 
Carlos G. Mendioroz  <tron@mrecvax.mrec.ar>  
Work: +54 (1) 313-8082  Fax: +54 (1) 311-1249
Home: +54 (1) 71-3473 ; Malabia 2659 11 B, Buenos Aires, 1425 ARGENTINA