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,fb45e48e8dddeabd X-Google-Attributes: gid103376,public X-Google-Thread: ffc1e,fb45e48e8dddeabd X-Google-Attributes: gidffc1e,public From: Laurent Guerby Subject: Re: Ada Protected Object Tutorial #1 Date: 1999/12/19 Message-ID: <86ogbn6ttu.fsf@ppp-166-211.villette.club-internet.fr>#1/1 X-Deja-AN: 562603236 References: <839toq$pu$1@bgtnsc03.worldnet.att.net> <385AC716.7E65BD5C@averstar.com> <83hi68$75k$1@nntp4.atl.mindspring.net> X-Trace: front5m.grolier.fr 945603442 11303 195.36.166.211 (19 Dec 1999 11:37:22 GMT) Organization: Club-Internet (France) NNTP-Posting-Date: 19 Dec 1999 11:37:22 GMT Newsgroups: comp.programming.threads,comp.lang.ada Date: 1999-12-19T11:37:22+00:00 List-Id: kaz@ashi.footprints.net (Kaz Kylheku) writes: > POSIX is an interface which can also be implemented such that it > handles common situations without calling into an operating system. > A trivial example of that would be seizing a pthread_mutex_t lock > when there is no contention. The POSIX threading functions are not > necessarily system calls. > > Just because something is not built into the language syntax, and > the name of its specification rhymes with UNIX doesn't mean that > it's a call into the opearting system. I believe what Steve said had nothing to do at all with the implementation of POSIX as system calls or whatever, he was talking semantics. Some seemingly simple Ada concurrency constructs can lead to a very complex POSIX calls/lock/condition scheme, complex not necessarily meaning inefficient implementation in this context, just that some of the semantic complexity is taken care of by your implementation. > 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. I believe you know about the Ada requeue statement (9.5.4) if you're talking about collaborating objects, right? > 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. One thing you're missing is that with protected objects and the Ada queue/barrier model there is no mandatory unlocking/relocking involved when there is "contention". The implementation can use same thread that made the condition true for other threads to continue service other threads that were blocked on an entry with a flase barrier. - at t=t0, T1 is inside PO.S1, T2 is blocked on PO.S2 with barrier B2. - at t=t1, T1 finishes PO.S1 code, the Ada runtime still in T1 context reevaluate B2, finds it true and will execute PO.S2 still witin T1 context at the end of PO.S2 code, T2 is released and T1 thread might continue to do other things on PO. Note here that it is one implementation model, but it is not the only one, an implementation is free to do "inefficient" locking/unlocking all over the place, or to use one or more internal thread to execute PO code if it believes it is more efficient. RM 9.5.3: RM> 22 An implementation may perform the sequence of steps of a protected RM> action using any thread of control; it need not be that of the task RM> that started the protected action. If an entry_body completes without RM> requeuing, then the corresponding calling task may be made ready RM> without waiting for the entire protected action to complete. RM> RM> 22.a Reason: These permissions are intended to allow RM> flexibility for implementations on multiprocessors. On a RM> monoprocessor, which thread of control executes the protected RM> action is essentially invisible, since the thread is not RM> abortable in any case, and the "current_task" function is not RM> guaranteed to work during a protected action (see C.7). > 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? As for anything related to performance, you have to provide a specific benchmark that defines what "scalability" you are talking about here, otherwise we'll be stuck in meaningless discussions. Also assuming that the Ada implementation uses POSIX thread, you can always at least get the same "scalability" (if it proves to be good) by coding directly your POSIX calls the way the Ada implementation does, but then you'll probably get a more meaningful comparison by looking at the POSIX vs Ada complexity of code. Also I believe your experience is exceptional with super-complex concurrent systems, what are you implementating for a living? --LG