Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Atomic operations (Was Re: Living With Old Baggage)
Keywords: 68040 CAS2
Message-ID: <3413@crdos1.crd.ge.COM>
Date: 14 May 91 15:35:26 GMT
References: <1991May2.201917.15062@dg-rtp.dg.com> <1991May6.113149.14531@decvax.dec.com> <1991May13.140634.17669@dg-rtp.dg.com> <1991May14.033023.26083@iecc.cambridge.ma.us>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 21

In article <1991May14.033023.26083@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes:

| Many people seem to believe that one can't do useful synchronization without
| disabled interrupts, spin locks, or some other scheme that makes one
| processor hang around and wait for another one to get out of its way.  They
| are wrong.

  Spin locking is generally less wasteful of CPU than a complete context
switch to a process which is not blocked, and back again. There are only
two types of lock which seem to make sense to me: for short action a
spin lock, and for long stuff something like pseudo-io which blocks the
waiting process and enables it back to the dispatcher when the inlock
occurs.

  Short is anything up to 4x a context switch, since a spin lock will
average half the worst case time and a block will always cost 2x context
switch. 
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
        "Most of the VAX instructions are in microcode,
         but halt and no-op are in hardware for efficiency"