Path: utzoo!utgpu!jarvis.csri.toronto.edu!csri.toronto.edu!moraes
Newsgroups: comp.sys.sgi
From: mor...@csri.toronto.edu (Mark Moraes)
Subject: semaphores vs locks?
Message-ID: <1989Sep5.185510.7836@jarvis.csri.toronto.edu>
Organization: University of Toronto, CSRI
Date: 5 Sep 89 22:55:11 GMT
On an Iris4d multiprocessor, what is the difference between a semaphore
and a lock? I couldn't find any specific mention of the difference in
the documentation. As far as I can tell, semaphores have queues in
which threads wait till the semaphore is freed, whereas locks are
continuously retried (assuming ussetlock) with some delay.
For a system with hardware locks, which is faster/cheaper - a
semaphore or a lock? Does a lock consume much cpu time while spinning?
Is the cost of going to sleep and awakening on a semaphore high? Does
anyone have any numbers on these?
Is there a section of the manual summarizing the parallel facilities
available? (Suggestion: Perhaps a future release of the documentation
could group manual pages by subsection and alphabetically - i.e. all
manual pages for 3P together, rather than alphabetically across all
subsections) The following is a list I've created, with some attempt
to order them in 'recommended reading order'. Have I missed anything?
usinit, _utrace (3P) - semaphore and lock initialization routine
usconfig (3P) - semaphore and lock configuration operations
taskblock, taskunblock, tasksetblockcnt (3P) - routines to block/unblock tasks
taskcreate (3P) - create a new task
taskdestroy (3P) - destroy a task
taskctl (3P) - operations on a task
barrier, new_barrier, free_barrier (3P) - barrier functions
usnewlock (3P) - allocates and initializes a lock
usinitlock (3P) - initializes a lock
ussetlock, uscsetlock, uswsetlock, ustestlock, usunsetlock (3P) - lock routines
usfreelock (3P) - free a lock
usctllock (3P) - lock control operations
usnewsema (3P) - allocates and initializes a semaphore
usinitsema (3P) - initializes a semaphore
uspsema (3P) - attempt to acquire a semaphore
usvsema (3P) - frees a resource to a semaphore
ustestsema (3P) - return the value of a semaphore
uscpsema (3P) - attempts to acquire a semaphore, and fails if not possible
usfreesema (3P) - free a semaphore
usctlsema (3P) - semaphore control operations
usmalloc, usfree, usrealloc (3P) - user shared memory allocator
acreate, adelete, amalloc, afree, arealloc, acalloc, amallopt, amallinfo (3P)
- arbitrary arena main memory allocator
pcreate: pcreatel, pcreatev, pcreateve, pcreatelp, pcreatevp (3P) - create a process
m_fork, m_kill_procs, m_set_procs, m_get_numprocs, m_get_myid, m_next, m_lock,
m_unlock, (3P) - parallel programming primitives
sproc (2) - create a new share group process
blockproc, unblockproc, setblockproccnt (2) - routines to block/unblock processes
Thanks.
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!
ames!sgi!...@patton.sgi.com
From: j...@patton.sgi.com (Jim Barton)
Newsgroups: comp.sys.sgi
Subject: Re: semaphores vs locks?
Message-ID: <41392@sgi.sgi.com>
Date: 7 Sep 89 16:10:03 GMT
References: <1989Sep5.185510.7836@jarvis.csri.toronto.edu>
Sender: j...@patton.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 59
In article <1989Sep5.185510.7...@jarvis.csri.toronto.edu>, mor...@csri.toronto.edu
(Mark Moraes) writes:
> On an Iris4d multiprocessor, what is the difference between a semaphore
> and a lock? I couldn't find any specific mention of the difference in
> the documentation. As far as I can tell, semaphores have queues in
> which threads wait till the semaphore is freed, whereas locks are
> continuously retried (assuming ussetlock) with some delay.
>
Semaphores and spinlocks are standard OS primitives which have existed for
25 years or more. There are many professors and others who have made their
living writing textbooks about how to use these in operating systems. For
a description in a UNIX context, Maurice Bach's book, "The Design of the UNIX
Operating System" has a chapter dedicated to multiprocessing, where he
describes how these primitives work (be careful though - there is a bug
in the algorithm for psema() he gives).
Fundamentally, a spinlock is a loop in software that does the following:
while (!(location changes)) ;
Thus, the spinlock reacts very quickly when the location changes, but some
time may be wasted waiting for it.
A semaphore is a queue with a counter, using a spinlock to protect the queue
and the counter. Semaphores were originally designed by Edgar Dijkstra, as
documented in the seminal paper "Cooperating Sequential Processes" which
has been reprinted in hundreds of places.
I'm posting a section of the original kernel design document that goes
into some detail on this stuff.
> For a system with hardware locks, which is faster/cheaper - a
> semaphore or a lock? Does a lock consume much cpu time while spinning?
> Is the cost of going to sleep and awakening on a semaphore high? Does
> anyone have any numbers on these?
Cost of a lock < cost of a semaphore. A semaphore implies that a context
switch may happen, while none happens with a spinlock. The generic rule
is that if the time spent spinning on the average is greater than the
time to block a process and switch to another one, use a semaphore, else use
a spinlock.
>
> Is there a section of the manual summarizing the parallel facilities
> available? (Suggestion: Perhaps a future release of the documentation
> could group manual pages by subsection and alphabetically - i.e. all
> manual pages for 3P together, rather than alphabetically across all
> subsections) The following is a list I've created, with some attempt
> to order them in 'recommended reading order'. Have I missed anything?
>
The list given is complete. The parallel programmers guide is in final
edit now, and should be available from SGI Real Soon Now.
> Thanks.
-- Jim Barton
Silicon Graphics Computer Systems "UNIX: Live Free Or Die!"
j...@sgi.sgi.com, sgi!...@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb