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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.126.137 with SMTP id my9mr6644909obb.13.1392495600907; Sat, 15 Feb 2014 12:20:00 -0800 (PST) X-Received: by 10.140.108.180 with SMTP id j49mr629qgf.21.1392495600852; Sat, 15 Feb 2014 12:20:00 -0800 (PST) Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!uq10no22414751igb.0!news-out.google.com!s3ni20561qas.0!nntp.google.com!k15no21126978qaq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 15 Feb 2014 12:20:00 -0800 (PST) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=206.53.78.59; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 206.53.78.59 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Implementation Locks From: sbelmont700@gmail.com Injection-Date: Sat, 15 Feb 2014 20:20:00 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 2077 Xref: number.nntp.dca.giganews.com comp.lang.ada:184886 Date: 2014-02-15T12:20:00-08:00 List-Id: In the past, using other languages, I spent lots of time worrying about whe= ther I should use a spinlock or a semaphore based on how long an sequence o= f operations was expected to be and how many CPU's were on the system, and = wrote lots of overly complicated code to chose the best option in each situ= ation. Now in Ada, I have difficulty giving up the habit and lay awake at night wo= rrying about whether the implementation is going busy-wait or block for a p= rotected 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 CP= U's are in the system and the average time to wait? Should I just trust th= e runtime and try not to worry? Is there even anything I can do about it e= ither way? -sb