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,67c50b972ca3b532 X-Google-Attributes: gid103376,public From: heatwole@erols.com (Kevin D. Heatwole) Subject: Re: Realtime Ada Conferences Date: 1996/03/28 Message-ID: #1/1 X-Deja-AN: 144681002 references: <4j9j9f$620@hacgate2.hac.com> <315998AC.67AA@thomsoft.com> organization: Erols Internet Services newsgroups: comp.lang.ada Date: 1996-03-28T00:00:00+00:00 List-Id: In article , dewar@cs.nyu.edu (Robert Dewar) wrote: > A nice capability in the old Alsys technology, which I would expect to > carry over to the new Thompson technology is a very flexible way of > spefiying mapping tasks to threads, with 1-1 (use all OS threads) > and all-1 (simulate all threads) just being two extremes of a very > flexible way of specifying the mapping. I will let Ed say more > about this! Well, I don't know anything about the old Alsys technology, but our Ada runtime for AIX (part of our PowerAda product) supports such a flexible scheme. By default, all tasks are "simulated" but you can bind with the thread library to execute each task in a separate thread. You can also mix the tasks, some "simulated" and some in separate threads. We continue to support this flexible mapping because: 1. Older versions of AIX did not support threads and we wish to be compatible with these previous versions of AIX, and 2. Not all C library services and AIX system calls are thread-safe. AIX usually offers different thread safe routines for doing the same services, only with different names and different parameters. So, applications that require access to non-thread safe libraries can still use Ada tasking (the simulated version) more safely (but services like malloc/free are not reentrant in the non-thread library so "simulated" tasks still have to serialize access to to such services). 3. The thread primitives on AIX is much slower than the "simulated" primitives in the runtime. Rendezvous can be an order of magnitude slower. A task context switch from a "simulated" task to another "simulated" task takes only slightly more time than a procedure call (e.g., setjmp/longjmp times). But, doing the same thing for threaded tasks involves calls to the operating system call. For those of you who are interested in such things, one of the big reasons that the thread services are slower in the case of AIX is that there is no thread-specific memory directly available to the thread (all virtual memory is shared by all threads in the process). So, the thread services in the operating system often have to figure out what thread is calling them (i.e., pthread_self call) in order to find its thread-specific data. This pthread_self call is implemented as a table lookup using the current stack pointer as the key. Anyway, if IBM could dedicate a register or a memory segment for this information, things would be much zippier, but they can't change register usage conventions without affecting existing binaries. Of course, we are only talking about microseconds of time here. While "simulated" task rendezvous may be around 10 mics, the thread task rendezvous would be around 100 mics. In most applications, the tasks actually do a lot of other work and the small difference in rendezvous times may not be significant in the overall performance picture. So, for the time being, it is important to understand how Ada tasking is mapped onto your operating system services. There are distinct advantages and disadvantages to both mappings, but the serious application that uses concurrency should consider these aspects during implementation. The good news is that the rest of the world is finally recognizing that concurrency within a single program/process is a good thing to support and Ada has always made this capability much safer and easier to use. Kevin Heatwole OC Systems, Inc.