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: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again,
 Ada absent from DoD SBIR solicitation))
Date: 1996/11/26
Message-ID: <1996Nov26.184337.1@eisner>#1/1
X-Deja-AN: 200936204
x-nntp-posting-host: eisner.decus.org
references: <325BC3B3.41C6@hso.link.com>
 <heatwole-ya023180002511960851580001@news.his.com> <E1FnJC.HI4@world.std.com>
 <heatwole-ya023180002611960850350001@news.his.com> <E1I0KG.M4r@world.std.com>
x-nntp-posting-user: KILGALLEN
x-trace: 849051824/13880
organization: LJK Software
newsgroups: comp.lang.ada
Date: 1996-11-26T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <E1I0KG.M4r@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:

> Well, OS calls *are* inherently expensive, because you have to cross a
> protection boundary.  But for multi-threading within a single
> application, the protection boundary is pointless, IMHO.  After all,
> threads share memory, so they can trash one another's data -- trashing
> another task's return addresses is at least as bad as destroying the
> data associated with locks and so forth.

Some thread-relevant OS calls affect the scheduler data in cases
where the OS can schedule separate threads on separate CPUs. The
scheduler data is typically stored together for all appications,
and one would not want an application to trash the data for some
other application.

Larry Kilgallen