Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!ulysses!thumper!faline!bellcore!rutgers!mailrus!ames!pasteur!agate!saturn!fouts@lemming.
From: fouts@lemming. (Marty Fouts)
Newsgroups: comp.os.research
Subject: Question on thread/process scheduler interaction
Message-ID: <5296@saturn.ucsc.edu>
Date: 28 Oct 88 15:35:06 GMT
Sender: usenet@saturn.ucsc.edu
Organization: NASA Ames Research Center, Moffet Field, CA
Lines: 29
Approved: comp-os-research@jupiter.ucsc.edu



I have seen the following problem occur in a number of lightweight
process implementations and was wondering if anyone had a ready
solution:

N tasks (threads) are started on top of M processes on a
multiprocessor with P processors (N >= M >= P > 1).

The tasks involve synchronization which requires spending some amount
of time in a critical region.  This is usually implemented using a
semaphore protected critical region.

One task enters the critical region in one process.  While there, a
second task running on a different process spinlocks on the semaphore.
The two processes are actually running on different processors.

The process level scheduler preempts the process running the task in
the critical region leaving the second process at the spinlock.  The
worst case is when the process is preempted by a third process
belonging to the same job which also reaches the spinlock.

Marty
--
+-+-+-+     I don't know who I am, why should you?     +-+-+-+
   |        fouts@lemming.nas.nasa.gov                    |
   |        ...!ames!orville!fouts                        |
   |        Never attribute to malice what can be         |
+-+-+-+     explained by incompetence.                 +-+-+-+