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: geert@fozzie.sun3.iaf.nl (Geert Bosch)
Subject: Re: Fast locking (Was Re: Java vs Ada 95)
Date: 1996/11/08
Message-ID: <55vbnj$o9p@fozzie.sun3.iaf.nl>#1/1
X-Deja-AN: 195359069
references: <325BC3B3.41C6@hso.link.com>
 <EACHUS.96Nov1103759@spectre.mitre.org> <E07Dwq.5L@world.std.com>
 <55gkch$gg6@fozzie.sun3.iaf.nl> <E0B6CL.84r@world.std.com>
 <dewar.847053681@merv> <55o4g4$ki8@fozzie.sun3.iaf.nl>
 <1996Nov5.235745.1@eisner> <55r16k$m00@fozzie.sun3.iaf.nl>
 <1996Nov7.073254.1@eisner>
organization: La Calandre Infortunee
newsgroups: comp.lang.ada
Date: 1996-11-08T00:00:00+00:00
List-Id: <comp.lang.ada>


Larry Kilgallen (kilgallen@eisner.decus.org) wrote:
   "Blocking all interrupts" in a multiprocessor environment would be
   hazardous to the speed of other, non-interfering, activities.

Please don't twist my words. I specifically said for that this
solution might be good for small/old systems. If you need an example,
think of microcontrollers.

I also wrote:
   "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"

How could you still think I was suggesting that "Blocking all interrupts"
in a multiprocessor environment was a good idea? A multiprocessor system
without test-and-set or similar mechanisms falls into the category:
   "[...] 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.

Larry wrote:
  "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".  "

I never said that, although test-and-set is the most well-known
primitive in this area, so I used that. I even listed some of the
other possible primitives. In any case, the test-and-set operation
can easily be implemented with other fast-locking operations. 

And the point is not that these low-level locks should be used in
most applications, but that they can be very valuable tools in
cases where they are needed just like the other parts of Annex C
of the ARM.

Larry wrote:
  "DEC designers made the choice that their "load-locked/
   store-conditional" semantics would be faster than more traditional
   approaches."

If I use that instruction as load-locked/store-whenzero than I have the
equivalent of test-and-set, which is why it makes sense to provide a
very generic fast-locking primitive like test-and-set in Ada
implementations rather than using DECs instruction-of-the-day.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl