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.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Implementation Locks
Date: Sat, 15 Feb 2014 14:34:29 -0700
Organization: Also freenews.netfront.net; news.tornevall.net
Message-ID: <ldomh6$6ec$1@dont-email.me>
References: <a6f65ae0-faf4-45eb-8a9c-f080fde3d58d@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 15 Feb 2014 21:34:31 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="6bab1dce10a849dba13303bd95a0f77d";
	logging-data="6604"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+SgtVT07LiyyKZFSU1/Jm9cJSowa56Les="
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.3.0
In-Reply-To: <a6f65ae0-faf4-45eb-8a9c-f080fde3d58d@googlegroups.com>
Cancel-Lock: sha1:E5XSPOn81JKwpQUYvdaw/7VKt7o=
Xref: news.eternal-september.org comp.lang.ada:18589
Date: 2014-02-15T14:34:29-07:00
List-Id: <comp.lang.ada>

On 02/15/2014 01:20 PM, sbelmont700@gmail.com wrote:
>
> Now in Ada, I have difficulty giving up the habit and lay awake at night
> worrying about whether the implementation is going busy-wait or block for a
> protected action or closed entry, especially now that everyone has multicore
> CPU's.  I'm particularly consternated by closed entries, since I doubt the
> compiler can predict whether it will open back up in several microseconds or
> in several days.  Is it unreasonable to expect an implementation to use some
> sort of dynamic, hybrid model that takes into account both how many CPU's are
> in the system and the average time to wait?  Should I just trust the runtime
> and try not to worry?  Is there even anything I can do about it either way?

You should trust the implementation, and measure your results. If you're meeting 
your timing requirements, then you have nothing to worry about.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70