Newsgroups: comp.unix.wizards,comp.parallel,comp.sys.sgi,alt.unix.wizards
From: kab@reed.edu (Kent Black)
Subject: Help with STREAMS sync for MP Solaris/SGI
Organization: Reed College,  Portland, Oregon
Date: 31 May 1995 22:09:52 GMT
Message-ID: <3qipfg$fpj@news.iastate.edu>

What is a/the proper procedure (preferably portable) for STREAMS module
delays and synchronization under multi-processor SGI IRIX 5.x and SUN
Solaris 2.x+ systems?

I'll gladly accept a solution that answers one platform.

This is a module pushed under the tty STREAM head, and not the STREAM
head/driver itself (the head would be easier).

	I need to send a command to a device to service a user ioctl
(but note that ioctl's are really a bit different under MP systems).
I need to wait for a rather lengthy time (~200-500ms) before I know
success, and I cannot allow further commands to go to the device until
that time has elapsed (or in some cases, I can continue immediately
when I get an appropriate response from the device).  To be concrete
I'll give two typical cases:
	1) device reset requires
		send command
		status could be returned immediately
		wait 200ms, ignoring/dumping output --
			Must Not send further commands during this time

	2) device probe requires
		send command -- status cannot be returned yet
		wait until complete reply from device (~50-250ms)
			OR timeout
		if timeout without complete reply then
			restore driver to stable state
			send alternate command
			wait until complete reply (~100-400ms) OR
				timeout
		return status

For the first case, I would naively want to grab a mutex token and
hold if for 200ms.  For the second I would naively want to block on a
mutex semaphore until either the reply was finished or a watchdog timer
expired and released the semaphore.  Both SGI and Solaris appear to
have all the tools I've described but there is one big gotcha: STREAMS
ioctls on MP systems appear to lack any context for sleeping (STREAMS
ioctls are really messages pushed down the STREAM).

The big waits are mostly during device initialization, although that
is small comfort since that's done at ioctl INITDEVICE, not on
open().  But even without the big waits, I have a bunch of ioctls that
need shorter (~10ms) long waits (too long to spinlock without causing 
noticeable if infrequent UI freezes), so the problem is general.  Surely
this is not an unusual situation?  Don't other devices (spaceball,
etc) have similar requirements, at least on startup?

Waiting eagerly, please email replies,
-- kab




