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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: ffc1e,fb45e48e8dddeabd X-Google-Attributes: gidffc1e,public X-Google-Thread: 103376,fb45e48e8dddeabd X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Ada Protected Object Tutorial #1 Date: 1999/12/19 Message-ID: <83j2il$da7$1@nnrp1.deja.com> X-Deja-AN: 562592801 References: <839toq$pu$1@bgtnsc03.worldnet.att.net> <385AC716.7E65BD5C@averstar.com> <83hi68$75k$1@nntp4.atl.mindspring.net> X-Http-Proxy: 1.0 x21.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Sun Dec 19 16:53:41 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.programming.threads,comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-12-19T00:00:00+00:00 List-Id: In article , kaz@ashi.footprints.net wrote: > The protected types as described are utterly useless to me > because of the limitations of what they can do. I can't think > of any software I have written in the past two years in which > protected types could have been applied (had I been working in > Ada). In almost everything I have done, there are complex > relationship among the collaborating objects. There are calls > among the objects from within critical regions, as well as > condition waits in arbitrary places. You have not quite got the idea yet :-) For such complex collaborating objects, we use tasks in Ada. Indeed everything that can be done with a protected object can be done with a task, it is just that tasks require more apparatus and hence have higher overhead. Protected objects are typically used to provide low level data oriented synchronization primitives. For example it is straightforward to construct a classical semaphore using a protected type, or (and this is the important point) any other similar synchronization mechanism, customized to the needs of your application. > Non sequitur. I was talking about the cost of implementing > specific semantics, such as atomically passing ownership of a > locked object to a specific thread so that the thread doesn't > have to re-evaluate a predicate. But keeping track of ownership is pretty critical for the purposes of implementing priority inheritance. One of the important features of Ada is that much of the programmer's job in avoiding priority inversion is automatic. There was incidentally no wishy-washy in the response, you just missed the underlying point :-) > The fact is, if you have a thread running on another processor > that is about to seize a lock, and you have to suspend that > thread because the current owner is passing ownership of the > lock to some specific thread, that is a waste of processor > time. It is never a waste of processor time to be careful about priority inversions. The world is scattered with examples of real time applications that have been written ferociously carefully to minimize task switching etc, but because of priority inversion fall on their faces. As always choosing the correct algorithms is more important, and implementing incorrect or dangerous algorithms efficiently is not a good substitute! You are really operating from an insufficient knowledge of Ada here. I would recommend reading the Burns and Welling book on real time programming (this is not entirely Ada specific, but it does give a good view of how common real time paradigms are implemented in Ada). See www.adapower.com for a full reference. > I'd like to hear from somone who has experience with these > so-called protected types on a machine with 16 processors or > more. What is the scalability like of existing > implementations? Our SGI customers use protected types routinely in SGI multi-processor machines, and they work just fine. Again, your problem is that you have the wrong view of protected types. They are low level gizmos that simply provide basic access to simple locking operations from which other primitives can be constructed. For example, if you want a little array that multiple processors need to read and write with appropriate protection, then at the OS level, you need a lock and you need to set and free the lock appropriately, and you need to worry about priority inversion effects that could happen if you don't worry about them (e.g. from a high priority task preempting a low priority task that owns the lock). All this would be automated with a simple protected type in Ada, including worrying about inversion (that's achieved by the use of ceiling priority protocol, which is of course a super efficient method on a single processor, and still probably the best approach on a multi-processor, but you do need an OS level lock in this case). There is certainly nothing magic in Ada, but what Ada gives you is a) A semantic abstraction level that is one step above the direct posix primitives, resulting in safer, easier to maintain code. This abstraction is achieved without introducing any significant inefficiency. b) Full portability. Even fully standards compliant posix implementations vary in ways that can compromise protability. For example, if you raise your priority, and then lower it, can you lose control to an equal priority task? Answer for POSIX is may be -- implementation dependent. Answer for Ada is no. Robert Dewar Ada Core Technologies P.S. since this goes to comp.programming.threads, it is perhaps appropriate to remind people that complete production quality Ada 95 compilers for all common targets are freely available. Go to the FTP directory pub/gnat at cs.nyu.edu for details. There you will find public releases of the GNAT technology. These are intended for student and research use, and are just the thing for familiarizing yourself with the advantages that Ada can bring to threads oriented programming. Corresponding fully supported commercial versions of GNAT Professional are available from Ada Core Technologies (sales@gnat.com). Sent via Deja.com http://www.deja.com/ Before you buy.