Conference azur::mcc

2920.0. "thread synchronization != thread scheduling" by TOOK::BURGESS () Sat May 02 1992 13:12

Thread synchronization is controlled via the synchrnonization primitives
which operate on 
	mutexes (lock, unlock, create, delete, try_lock)
	condition variables (create,delete, signal, broadcast, wait)

Refer to Birrell's introduction to thread programming and numerous other
papers which discuss the proper use of mutexes, condition-variables, predicates, 
and invariants to achieve *correct* synchronization.

\Pete


================================================================================
Note 441.6             O.S. support for scheduling threads                6 of 7
R2ME2::BUTENHOF "Better Living Through Concurrency!" 37 lines  30-APR-1992 11:37
                         -< POSIX "Contention Scope" >-
--------------------------------------------------------------------------------
BEWARE of relying on priority-ordered scheduling by threads within different
processes. There is no standard or portable way to control the behavior of
these threads with respect to each other.

DECthreads is based on the IEEE 1003.4a threads standard. While the scheduling
chapter makes some attempt to establish some parameters which would in theory
allow the implementation to specify how such interactions occur, there is no
requirement that the mechanisms be implemented. This is the "contention scope"
attribute, which may be set to "global" (possibly contending equally with all
threads in the "system") or "local" (where priority is meaningful only within
a process). However, there is no requirement that any system support both
global and local, nor is there any way for an application to tell. In fact,
there is also a good deal of controversy over the meaning of "system" in this
context, and the semantics (loose as they already are) may change for the
next draft.

The standard "kernel" (Mach thread based) DECthreads on DEC OSF/1 V1.0 operates
solely in global contention scope. Except that due to Mach thread limitations,
we don't support priority at all on that version, so (as the Borg might say),
"priority inversion is irrelevant" (no thread has any priority). On all other
platforms, DECthreads operates solely in local contention scope; effectively a
two-level priority where processes compete based on their priorities for CPU
time, and only once a threaded process has acquired the CPU do its threads
compete based on their priorities.

DECthreads does not even implement the P1003.4a functions to get or set a
thread's contention scope: they were added for draft 5 of the standard, where
DECthreads implements draft 4 (balloting on draft 6 closes tomorrow, May 1,
and we expect there will be at least one more draft before we achieve a formal
standard).

My advice would be to avoid coding priority inversions between processes,
because global contention scope is a long way off on all current DECthreads
platforms, and may very well never materialize even when and if the kernel
support arrives.

	/dave