Article 160020 of comp.os.vms:
In message <329c4e5b.7956765@news.op.net>, dockray@ACM.org (Tom Dockray) writes:
>My problem is this. If I read the mailbox with a QIOW, it will block the
>entire process, not just the thread in which the QIOW is issued. I could
>use a QIO with an AST, but how do I safely unblock a thread in an AST
>and hand a message off to it? Using MUTEX lock/condition wait in an AST
>environment would appear to offer the opportunity for a deadlock.

The technique I use is to replace:

	status = sys$qiow ( 0, chan, fcode, &iosb, 0, 0,
		p1, p2, p3, p4, p5, p6 );
	if ( (status&1) == 1 ) status = iosb.status;

with:

	pthread_mutex_lock ( &mutex );
	status = sys$qio ( 0, chan, fcode, &iosb, pthread_cond_signal_int_np,
		&cond, p1, p2, p3, p4, p5, 6p );
	if ( (status&1) == 1 ) {
	    do { pthread_cond_wait(&cond, &mutex); } while (iosb.status == 0);
	    status = iosb.status;
	}
	pthread_mutex_unlock ( &mutex );

Note that the signal is done with a special function intended to be called
from AST level.  Condition variables under VMS are implemented so that signals
issued via pthread_cond_signal_int_np() will mark a 'signal pending' which
pthread_cond_wait() detects to avoid a deadlock.

Since VMS V7.0 came out, I usually wrap the entire idiom into a macro
(QIO_AND_WAIT) so that it can easily be changed to support kernel thread
upcalls when available.


David L. Jones               |      Phone:    (614) 292-6929
Ohio State Unviversity       |      Internet:
2070 Neil Ave. Rm. 122       |               jonesd@kcgl1.eng.ohio-state.edu
Columbus, OH 43210           |               vman+@osu.edu

Disclaimer: Dogs can't tell it's not bacon.


