From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Fast locking (Was Re: Java vs Ada 95) Date: 1996/11/07 Message-ID: <1996Nov7.073254.1@eisner>#1/1 X-Deja-AN: 195069922 x-nntp-posting-host: eisner.decus.org references: <325BC3B3.41C6@hso.link.com> <55gkch$gg6@fozzie.sun3.iaf.nl> <55o4g4$ki8@fozzie.sun3.iaf.nl> <1996Nov5.235745.1@eisner> <55r16k$m00@fozzie.sun3.iaf.nl> x-nntp-posting-user: KILGALLEN x-trace: 847369977/8094 organization: LJK Software newsgroups: comp.lang.ada Date: 1996-11-07T00:00:00+00:00 List-Id: In article <55r16k$m00@fozzie.sun3.iaf.nl>, geert@fozzie.sun3.iaf.nl (Geert Bosch) writes: > I can't imagine there are many systems around these days that do not > provide efficient test-and-set semantics. Even the 8088 processor that > does not directly have a test-and-set instruction can easily emulate > one by doing an atomic swap between a processor register and a memory > location. On very simple processors it is almost always possible to > block all interrupts while doing the test-and-set. "Blocking all interrupts" in a multiprocessor environment would be hazardous to the speed of other, non-interfering, activities. > Of course machines that do not have any instructions that can be used > to efficiently implement hardware-assisted locking will not have a > test-and-set intrinsic sub-program, but of course nobody expects to > magically be able to use hardware locking support when the target > platform does not have it. The point is that *when* it is available, > it should be usable in a consistent way. My complaint is not that some machines lack fast locking primitives, but rather that there was an assumption that those primitives will always be "test and set". DEC designers made the choice that their "load-locked/store-conditional" semantics would be faster than more traditional approaches. Since they consistently win the SpecFP and SpecInt comparisons with each new chip, I presume they know what they are doing about fast hardware (although the portion of their design having to do with locking primitives has nothing to do with the portion of their design needed for the rather limited SpecFP and SpecInt tests). Larry Kilgallen