Re: rendez-vous underlying mechanism

[kcline17@hotmail.com (Kevin Cline)]

"Pat Rogers" <progers@classwide.com> wrote in message news:<HgXs8.1415$L95.632339599@newssvr11.news.prodigy.com>...
> "Kevin Cline" <kcline17@hotmail.com> wrote in message
> news:ba162549.0204080905.24486c34@posting.google.com...
> > Richard Riehle <richard@adaworks.com> wrote in message
>  news:<3CA2A827.11140295@adaworks.com>...
> > > Kevin Cline wrote:
> > >
> > > > "Bozo" <gri_nob@yahoo.com> wrote in message
>  news:<a7pk89$kj4$1@bcarh8ab.ca.nortel.com>...
> > > > > Hi all,
> > > > >
> > > > > I'm sorry I wasn't clear enough.
> > > > > I don't use ADA at the moment but I was a brave ADA programmer once.
> > > > > I use C at the moment and I have a case where synchronous rendez-vous
>  would
> > > > > be better that traditional asynchrounous intertask communications.
> > > > >
> > > > > Does anyone have an idea how to implement that in C with semaphores for
> > > > > example ?
> > > >
> > > > This depends on the underlying OS.  If you are using pthreads,
> > > > then see the manual entry for pthread_cond_wait.
> > >
> > > This approach, of course, does not come close to the capabilities
> > > already built-in to the Ada tasking model.    Ever heard of protected
> > > types.
> >
> > I know that.  However, in a hosted environment, the imperfect
> > mapping between the Ada tasking model and the underlying OS facilities
> > can catch programmers by surprise.
> 
> When was this?  You say that as if it is the current norm -- and it certainly
> was in the 1980's -- but surely not still.  The compilers I know about that
> target Un*x or Linux map tasks directly to the underlying OS's threads, not
> their processes.  The old Verdix compiler did that many years ago (i.e., mapped
> tasks to sprocs).
> 
> > I was certainly surprised
> > when I attempted to create a separate task for I/O but found that
> > all tasks blocked anyway because they were mapped to a single Unix thread.
> > On that implementation Ada multi-tasking was uselsss for solving
> > problems routinely handled with Posix threads.
> 
> Agreed; an undesirable implementation if the option of mapping tasks to Pthreads
> was not available, but that's my point -- that was a given implementation that I
> don't believe is not the norm today.

It doesn't matter much whether it's the norm.  If the language standard
doesn't guarantee any useful semantics then programs that use the
Ada tasking model for the aforementioned purpose are not portable
across compilers.