Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!paperboy!osf.org!nick
From: nick@osf.org (Nick Dokos)
Newsgroups: comp.unix.ultrix
Subject: Re: CMA threads usage?
Message-ID: <1991Jan10.173758@osf.org>
Date: 10 Jan 91 22:37:58 GMT
References: <331@oiscola.Columbia.NCR.COM>
Sender: news@OSF.ORG
Reply-To: nick@osf.org (Nick Dokos)
Distribution: na
Organization: Open Software Foundation
Lines: 30

My understanding is that the architecture does not specify the
degree of parallelism but strongly encourages the thread-synchronous
model (only the thread executing the blocking call is blocked).

Quoting from the CMA document (Ch. 6: Operating System Support for CMA
Services, p.71):
" A reentrant service is thread-serial if, when it must block, it blocks
the current thread and all other threads that might attempt to call the
same service until the first call returns.

A reentrant service is said to be thread-synchronous if, when it must block,
it blocks only the current thread, and other threads can execute the same
operation during the blockage.

For many services, providing thread-serial reentrancy is adequate, but
implementations should try hard to provide thread-synchronous I/O
services (any service with a long latency is best made thread synchronous).
This is more work than merely making services serially reentrant, but it is
urgently needed by I/O intensive applications."

In other words, blame the implementation :-) BTW, what implementation
are you using and on what version of Unix?

Same is true of the scheduling policy: the architecture provides for
the most rudimentary scheduling controls and leaves the detailed 
properties of scheduling to the implementation (p.8 of the CMA doc).

-- 
Nick Dokos		(nick@osf.org)
Systems Engineering	OSF