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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e81fd3a32a1cacd2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newscon02.news.prodigy.net!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Arguments for single-mutex-exclusion on protected types (Was: Does Ada tasking profit from multi-core cpus?) Date: Sun, 18 Mar 2007 13:57:20 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1174240640 16862 192.74.137.71 (18 Mar 2007 17:57:20 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 18 Mar 2007 17:57:20 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:Sn5tqL8gH+pRhvlq8lvquCmkOSU= Xref: g2news1.google.com comp.lang.ada:14551 Date: 2007-03-18T13:57:20-04:00 List-Id: "Randy Brukardt" writes: > I don't understand Jeffrey's point either, but isn't it true that ceiling > locking is essentially irrelevant on multiprocessor systems? That is, the > point is to get rid of the lock, but you can't do that on a multi-processor > (one processor can be running a lower priority task without anything being > wrong, and that task had better be blocked from accessing the protected > object). So ceiling locking has no advantage on a multi processor, it just > restricts what you can do. If multiple cores continue to grow in popularity, > it seems that the whole ceiling locking thing will become essentially > irrelevant - just another case of premature optimization. > > (Can you tell I don't like ceiling locking much??) On a multiprocessor, you can use ceilings plus spin locks to protect protected objects. The point is to avoid any queued waiting to enter a PO (all the queuing is done with entry queues in this model). That can be made quite efficient, and the ceilings still prevent certain forms of priority inversion. So, no, I don't think ceilings are entirely irrelevant on multiprocessors. Ceilings are largely irrelevant if you're building Ada tasking on top of some other system (posix or windows threads, for example) that wants to do things differently. I mean, if you're using the one-Ada-task-per-thread model. Another issue is that Ada's priority model has nothing to say about processor affinity. - Bob