Re: Query about monitor (passive) task optimization

[agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!u sc!hela.iti.org!widener!dsinc!gvls1!lonjers@ucbvax.Berkeley.EDU (Jim Lonjers)]

In article <1993Aug3.201003.448@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Fe
ldman) writes:

>So what do we have now? POSIX/Ada bindings. Packages. Subroutine calls.
>I'm not dumping on the good work done in developing the POSIX/Ada
>bindings; I'm saying that such things should not really be necessary,
>if the compilers were doing what we pay for them to do - give us good, 
>correct code that really exploits the hardware and the power of the language.

Mike, we appreciate the fact that you continue to be a supporter of the
quality of work done on the POSIX Ada bindings.  I am afraid the statement
quoted above may mislead some readers as to the intent of the POSIX Ada
bindings.  Our intent was not to provide alternate methods to accomplish
the same things as are available in the language, but to provide a
portable method of access to operations that either have no analogue
in the language, or there is no portable way to access them from a
correctly written Ada program.

For example, Ada provides no way to call on a program written in a
different language.  Yes, you can call on procedures written in other
languages (although not portably), but no mechanism to execute another
program.  This is not a deficiency in the Ada language, but a perfect
opportunity for a secondary standard to fill a gap.  Other areas that were
filled by the POSIX Ada standard is specification of file names, a
definition of the mapping of Ada files onto OS files (to aid in
inter-language cooperation) and portable signal handling, to name a few.

In all of these cases, it is not a lack of quality implementations, but
simply a lack of a common definition for how the implementors should
express the concepts.

Throughout the deliberations on the standard, it was debated whether a
binding interface to a feature should be provided, or whether to allow
access to particular OS functions up to the compiler.  If the concept could
be presented clearly in Ada, a binding to the feature was not produced.

Similar deliberations are underway right now on the POSIX Ada Realtime
standard, with the debate being obviously most heated on how much of the
POSIX threads interface to reveal and how much to hide behind the tasking
model, and how much of the mapping between tasks and threads to define.
Clearly this work is being heavily influenced by 9X.  Your help on these
decisions would be greatly appreciated.

Jim