rendez-vous underlying mechanism

rendez-vous underlying mechanism

[Bozo]

Hi all,

I'm jus wondering how a rendez-vous is done internally. I'd like to do
something resembling a rendez-vous in C and that would help me.

Thanks

Re: rendez-vous underlying mechanism

[Marin David Condic]

What do you mean by "done internally"? Generally speaking, the whole
business of task scheduling and communication is something that an Ada
compiler provides in part by how it compiles the statements and in part by
its available runtime and/or OS primitives. The rendezvous has to impact
scheduling of tasks, so it isn't typically something that can be done as
simply as a procedure call.

What exactly are you trying to accomplish? It is possible to cobble together
something resembling tasks and rendezvous in C provided you have proper OS
support, but you're really asking to make your life hard when it doesn't
necessarily have to be.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Bozo" <gri_nob@yahoo.com> wrote in message
news:a7n9qd$8kf$1@bcarh8ab.ca.nortel.com...
> Hi all,
>
> I'm jus wondering how a rendez-vous is done internally. I'd like to do
> something resembling a rendez-vous in C and that would help me.
>
> Thanks
>
>

Re: rendez-vous underlying mechanism

[Jeffrey Creem]

Wow..This one just never dies.. GNAT does not translae Ada code to C.
Prior versions of GNAT used to generate the main binder program in C (calls
to elaborate the
packages followed by a call to the main program) but even that is now gone.

There are compiler switches that you can use to see the expanded Ada code
but this is
certainly not C.

As to the original question, seems like a pretty boring rendevous since C
has no tasking. Now, if you
say C and some particular tasking run time library than one could begin to
construct something similar to
the Ada.

Which thread library is being targeted?

"Adrian Hoe" <mailbox@*nospam*adrianhoe.com> wrote in message
news:3c9fc639_2@news.tm.net.my...
> Bozo wrote:
> >
> > Hi all,
> >
> > I'm jus wondering how a rendez-vous is done internally. I'd like to do
> > something resembling a rendez-vous in C and that would help me.
> >
> > Thanks
>
>
> Why C? Ada allows you to define tasks explicitly compare to C. GNAT is
> actually "translating" Ada to C. So, you can use GNAT to generate C code
> and then examine it. I can't actually remember how to have the C
> translation. I had it once some time ago after an incomplete
> installation of GNAT. :)
> --
> Remove *nospam* to e-mail me.          -- Adrian Hoe
>                                        -- http://adrianhoe.com

Re: rendez-vous underlying mechanism

[Adrian Hoe]

Bozo wrote:
> 
> Hi all,
> 
> I'm jus wondering how a rendez-vous is done internally. I'd like to do
> something resembling a rendez-vous in C and that would help me.
> 
> Thanks


Why C? Ada allows you to define tasks explicitly compare to C. GNAT is
actually "translating" Ada to C. So, you can use GNAT to generate C code
and then examine it. I can't actually remember how to have the C
translation. I had it once some time ago after an incomplete
installation of GNAT. :)
-- 
Remove *nospam* to e-mail me.          -- Adrian Hoe
                                       -- http://adrianhoe.com

Re: rendez-vous underlying mechanism

[Adrian Hoe]

Adrian Hoe wrote:
> 
> Bozo wrote:
> >
> > Hi all,
> >
> > I'm jus wondering how a rendez-vous is done internally. I'd like to do
> > something resembling a rendez-vous in C and that would help me.
> >
> > Thanks
> 
> Why C? Ada allows you to define tasks explicitly compare to C. GNAT is
> actually "translating" Ada to C. So, you can use GNAT to generate C code
> and then examine it. I can't actually remember how to have the C
> translation. I had it once some time ago after an incomplete
> installation of GNAT. :)


Look for two files, "cc1" and "cpp" in your GNAT installation directory
(eg. /usr/lib/gcc-lib/i386-Ada-linux/2.8.1 on my box). I believe one of
them actually translate or pre-process Ada source to C.

I don't have the time to hack GNAT source to verify this. This is just a
pointer from my faint experience. After all I don't bother to translate
Ada to C. :)
-- 
Remove *nospam* to e-mail me.          -- Adrian Hoe
                                       -- http://adrianhoe.com

Re: rendez-vous underlying mechanism

[Jeffrey Creem]

cpp is the c-preprocessor..
cc1 is that C compiler "main"

You can delete both of them and still compile, link and run an Ada program.
(if you are going to "try this at home", please don't really delete them ;)


In any case, GNAT does not translate your code to C. I've spent more of my
free time than I care to admit looking at GNAT source code (for fun only).

Don't take my word for it. Take Rober Dewar's word. He knows a little bit
about the internals
of GNAT :)

http://groups.google.com/groups?q=gnat+translate+code+C+dewar&hl=en&lr=lang_
en&selm=dewar.888332671%40merv&rnum=1

http://groups.google.com/groups?q=gnat+translate+code+C+dewar&hl=en&lr=lang_
en&selm=5ee5b646.0108161722.2bf90e39%40posting.google.com&rnum=3

http://groups.google.com/groups?q=gnat+translate+code+C+dewar&hl=en&lr=lang_
en&selm=dewar.822772377%40schonberg&rnum=4


I am sure I can find a few more references.. In any case, it is a popular
misconception probably
caused by the original Acronym and the old method of the binder producing a
single C file.



"Adrian Hoe" <mailbox@*nospam*adrianhoe.com> wrote in message
news:3c9fcb98$1_1@news.tm.net.my...
> Adrian Hoe wrote:
> >
> > Bozo wrote:
> > >
> > > Hi all,
> > >
> > > I'm jus wondering how a rendez-vous is done internally. I'd like to do
> > > something resembling a rendez-vous in C and that would help me.
> > >
> > > Thanks
> >
> > Why C? Ada allows you to define tasks explicitly compare to C. GNAT is
> > actually "translating" Ada to C. So, you can use GNAT to generate C code
> > and then examine it. I can't actually remember how to have the C
> > translation. I had it once some time ago after an incomplete
> > installation of GNAT. :)
>
>
> Look for two files, "cc1" and "cpp" in your GNAT installation directory
> (eg. /usr/lib/gcc-lib/i386-Ada-linux/2.8.1 on my box). I believe one of
> them actually translate or pre-process Ada source to C.
>
> I don't have the time to hack GNAT source to verify this. This is just a
> pointer from my faint experience. After all I don't bother to translate
> Ada to C. :)
> --
> Remove *nospam* to e-mail me.          -- Adrian Hoe
>                                        -- http://adrianhoe.com
>

Re: rendez-vous underlying mechanism

[Simon Wright]

Adrian Hoe <mailbox@*nospam*adrianhoe.com> writes:

> Why C? Ada allows you to define tasks explicitly compare to C. GNAT
> is actually "translating" Ada to C. So, you can use GNAT to generate
> C code and then examine it. I can't actually remember how to have
> the C translation. I had it once some time ago after an incomplete
> installation of GNAT. :)

Very mysterious, GNAT has never translated to C. You can see the
_assembler_ output using -S (like most? all? GCC compilers).

If you are using GNAT, why not look at the RTS source? (mostly in Ada).

Re: rendez-vous underlying mechanism

[tgingold]

In article <3ca03f16$1_2@news.tm.net.my>, Adrian Hoe wrote:
> Simon Wright wrote:
>> 
>> Adrian Hoe <mailbox@*nospam*adrianhoe.com> writes:
>> 
>> > Why C? Ada allows you to define tasks explicitly compare to C. GNAT
>> > is actually "translating" Ada to C. So, you can use GNAT to generate
>> > C code and then examine it. I can't actually remember how to have
>> > the C translation. I had it once some time ago after an incomplete
>> > installation of GNAT. :)
>> 
>> Very mysterious, GNAT has never translated to C. You can see the
>> _assembler_ output using -S (like most? all? GCC compilers).
>> 
>> If you are using GNAT, why not look at the RTS source? (mostly in Ada).
> 
> 
> Strange. I got a C file somehow produced by GNAT which I did not
> properly installed. It was 3.10 if I remember correctly. At that time I
> was just trying to compile a simple "Hello World" program. My memory
> could serve me wrong but I am damned sure I got a C source file in my
> test directory which contained only an .adb file.
That was certainly the C file generated by the binder.
The current version of GNAT generates an Ada file by default.

Tristan.

Re: rendez-vous underlying mechanism

[Adrian Hoe]

Simon Wright wrote:
> 
> Adrian Hoe <mailbox@*nospam*adrianhoe.com> writes:
> 
> > Why C? Ada allows you to define tasks explicitly compare to C. GNAT
> > is actually "translating" Ada to C. So, you can use GNAT to generate
> > C code and then examine it. I can't actually remember how to have
> > the C translation. I had it once some time ago after an incomplete
> > installation of GNAT. :)
> 
> Very mysterious, GNAT has never translated to C. You can see the
> _assembler_ output using -S (like most? all? GCC compilers).
> 
> If you are using GNAT, why not look at the RTS source? (mostly in Ada).


Strange. I got a C file somehow produced by GNAT which I did not
properly installed. It was 3.10 if I remember correctly. At that time I
was just trying to compile a simple "Hello World" program. My memory
could serve me wrong but I am damned sure I got a C source file in my
test directory which contained only an .adb file.
-- 
Remove *nospam* to e-mail me.          -- Adrian Hoe
                                       -- http://adrianhoe.com

Re: rendez-vous underlying mechanism

[David C. Hoos, Sr.]

When building a program with older versions of GNAT, you
would get a C file produced by the gnatbind step.  E.g.,
if your main program was in hello.adb, the file produced
would be named b_hello.c

If you built with the -g option, the C file and its object
would be retained -- if not, they were deleted.

But, know also, that in such a case, there would be both
a hello.o and a b_hello.o file in your directory.

In more recent versions of GNAT, the bind file can be
generated in either Ada or C (the default is Ada).  In
the case of Ada bind files, there is both a spec and a body,
files named b~hello.ads, and b~hello.adb, for a hello.adb
main program.

All of this is thoroughly documented in the GNAT User's
Guide, along with an explanation of the content and purpose
of these files.

I have been using GNAT since 3.04, and at no time ever
was any Ada code translated to C, by any of these versions.

----- Original Message ----- 
From: "Adrian Hoe" <mailbox@*nospam*adrianhoe.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: March 26, 2002 4:17 AM
Subject: Re: rendez-vous underlying mechanism


> Simon Wright wrote:
> > 
> > Adrian Hoe <mailbox@*nospam*adrianhoe.com> writes:
> > 
> > > Why C? Ada allows you to define tasks explicitly compare to C. GNAT
> > > is actually "translating" Ada to C. So, you can use GNAT to generate
> > > C code and then examine it. I can't actually remember how to have
> > > the C translation. I had it once some time ago after an incomplete
> > > installation of GNAT. :)
> > 
> > Very mysterious, GNAT has never translated to C. You can see the
> > _assembler_ output using -S (like most? all? GCC compilers).
> > 
> > If you are using GNAT, why not look at the RTS source? (mostly in Ada).
> 
> 
> Strange. I got a C file somehow produced by GNAT which I did not
> properly installed. It was 3.10 if I remember correctly. At that time I
> was just trying to compile a simple "Hello World" program. My memory
> could serve me wrong but I am damned sure I got a C source file in my
> test directory which contained only an .adb file.
> -- 
> Remove *nospam* to e-mail me.          -- Adrian Hoe
>                                        -- http://adrianhoe.com
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: rendez-vous underlying mechanism

[Bozo]

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 ?

Thanks




"Bozo" <gri_nob@yahoo.com> wrote in message
news:a7n9qd$8kf$1@bcarh8ab.ca.nortel.com...
> Hi all,
>
> I'm jus wondering how a rendez-vous is done internally. I'd like to do
> something resembling a rendez-vous in C and that would help me.
>
> Thanks
>
>

Re: rendez-vous underlying mechanism

[Marin David Condic]

Yes, but you'll have to check for the available OS or compiler supplied
tools to do the job. Basically, you need a means of making some functions
that run as threads. That's usually some kind of OS call. Likewise, you need
some kind of semaphore or flag (Two of them) on which the threads will
block. (Again, that will likely be an OS call.) When you've got two
functions running in parallel and you want to do the equivalent of the
rendesvous, they need to flag each other via the semaphores

If you have a writer of data and a reader of data, they need to do the
following: The writer sets up the data, then trips the flag for the reader
saying "Go ahead and read the data". It must then immediately block on a
flag that the reader is going to set that indicates "The data has been
read". From the reader's perspective, it is going to hang on the flag that
says "Its OK for me to read the data now." When it has copied the data (or
done whatever it would do in the accept statement in Ada.) it finishes its
part by setting the flag indicating "The data has been read" The writer is
then allowed to proceed.

The specifics are going to depend entirely on what OS calls or compiler
utilities you have available. You might find that out from a C newsgroup if
you don't already know.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"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 ?
>
> Thanks
>
>
>
>
> "Bozo" <gri_nob@yahoo.com> wrote in message
> news:a7n9qd$8kf$1@bcarh8ab.ca.nortel.com...
> > Hi all,
> >
> > I'm jus wondering how a rendez-vous is done internally. I'd like to do
> > something resembling a rendez-vous in C and that would help me.
> >
> > Thanks
> >
> >
>
>

Re: rendez-vous underlying mechanism

[Kevin Cline]

"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.

Re: rendez-vous underlying mechanism

[Adrian Hoe]

Adrian Hoe wrote:
> 
> Simon Wright wrote:
> >
> > Adrian Hoe <mailbox@*nospam*adrianhoe.com> writes:
> >
> > > Why C? Ada allows you to define tasks explicitly compare to C. GNAT
> > > is actually "translating" Ada to C. So, you can use GNAT to generate
> > > C code and then examine it. I can't actually remember how to have
> > > the C translation. I had it once some time ago after an incomplete
> > > installation of GNAT. :)
> >
> > Very mysterious, GNAT has never translated to C. You can see the
> > _assembler_ output using -S (like most? all? GCC compilers).
> >
> > If you are using GNAT, why not look at the RTS source? (mostly in Ada).
> 
> Strange. I got a C file somehow produced by GNAT which I did not
> properly installed. It was 3.10 if I remember correctly. At that time I
> was just trying to compile a simple "Hello World" program. My memory
> could serve me wrong but I am damned sure I got a C source file in my
> test directory which contained only an .adb file.
> --


Ok. I am wrong and I owe everyone an apology for my stupidity. :)
-- 
                                       -- Adrian Hoe
                                       -- http://adrianhoe.com

Re: rendez-vous underlying mechanism

[Richard Riehle]

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.

Richard Riehle

Re: rendez-vous underlying mechanism

[Marin David Condic]

In fairness, the original poster did seem to be stipulating that while he
knew & liked Ada, he was constrained by the tools at hand. Sure, the Ada
tasking model is (IMHO) infinitely preferable to attempting to simulate the
same thing in C. But if all you have is C, you can still get all the same
capabilities by using OS operations to roll your own. It hurts a lot - and I
really hate it when that happens - but you can get there. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3CA2A827.11140295@adaworks.com...
>
> This approach, of course, does not come close to the capabilities
> already built-in to the Ada tasking model.    Ever heard of protected
> types.
>
> Richard Riehle
>
>

Re: rendez-vous underlying mechanism

[Pascal Obry]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

>         Didn't I read somewhere that GNAT started life as the NYU Ada/Ed
> system mated to the GNU GCC complex?

That is maybe something you read somewhere... but it is plain wrong :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: rendez-vous underlying mechanism

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]


"Dennis Lee Bieber" <wlfraed@ix.netcom.com> a �crit dans le message news: a8olf7$enj$3@nntp9.atl.mindspring.net...
>         But didn't the old NYU Ada/Ed translator go via C?
No. It generated code for a virtual machine, that was then interpreted. The *interpreter* (in its ultimate version) was written in
C.

>         Didn't I read somewhere that GNAT started life as the NYU Ada/Ed system
> mated to the GNU GCC complex?
>
No, but it was written by the same people, so a lot of experience gained from Ada/Ed went into Gnat, but no code AFAIK.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: rendez-vous underlying mechanism

[Kevin Cline]

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.  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.

Re: rendez-vous underlying mechanism

[Ole-Hjalmar Kristensen]

kcline17@hotmail.com (Kevin Cline) writes:

> 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.  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.

Yes. The really bad thing about this is that your program will compile
and run, but not work as you had expected when you port it to a new
platform where Ada tasks has been impelented differently. 

Re: rendez-vous underlying mechanism

[Pat Rogers]

"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.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: rendez-vous underlying mechanism

[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.

Re: rendez-vous underlying mechanism

[Pat Rogers]

"Kevin Cline" <kcline17@hotmail.com> wrote in message
news:ba162549.0204100919.7cfc14dc@posting.google.com...
> "Pat Rogers" <progers@classwide.com> wrote in message
news:<HgXs8.1415$L95.632339599@newssvr11.news.prodigy.com>...
<snip>
> > > 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.

If you expect a language standard -- any language standard -- to specify such a
mapping to an operating system implementation you will remain "surprised".

Re: rendez-vous underlying mechanism

[Marin David Condic]

That may be true, but if you over-specify the semantics you can end up with
a situation where the feature is just too hard to implement in some places.
Is it better to have the semantics more specific and then only have a few
implementations (destroying portability along the way)? Or is it better to
be a little more loose with the requirements so that you can more easily
implement it on bare hardware, Unix, Windows, Macintosh, etc. etc. etc. and
rely on the developers to understand and work within the limitations? More
rigid requirements might have also closed out options that enable vendors to
provide multiple implementation choices (like round-robin,
run-until-blocked, etc) that gives the customer choices about what is best
for the particular app in question.

Everything is a compromise in the real world, so while I understand the
desire to have less ambiguity, you only get it by giving up something else.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Kevin Cline" <kcline17@hotmail.com> wrote in message
news:ba162549.0204100919.7cfc14dc@posting.google.com...
>
> 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.

Re: rendez-vous underlying mechanism

[Ole-Hjalmar Kristensen]

"Pat Rogers" <progers@classwide.com> writes:

> "Kevin Cline" <kcline17@hotmail.com> wrote in message
> news:ba162549.0204100919.7cfc14dc@posting.google.com...
> > "Pat Rogers" <progers@classwide.com> wrote in message
> news:<HgXs8.1415$L95.632339599@newssvr11.news.prodigy.com>...
> <snip>
> > > > 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.
> 
> If you expect a language standard -- any language standard -- to specify such a
> mapping to an operating system implementation you will remain "surprised".

Agreed, but it would be reasonable to see a language standard specify
that blocking a task would not block the entire program. It's a pity
it's not covered in the Ada standard.

Re: rendez-vous underlying mechanism

[Darren New]

Ole-Hjalmar Kristensen wrote:
> Agreed, but it would be reasonable to see a language standard specify
> that blocking a task would not block the entire program. It's a pity
> it's not covered in the Ada standard.

I think you'd get into all kinds of things about what "blocking a task"
means. For example, for a while I worked on one system where requesting
to allocate memory when there wasn't any swap space left got you swapped
out until some other program freed up memory. There's no way to not
block all the tasks if your process isn't in core. And it's just a
memory allocation doing this, not even any user-visible I/O.
 
If a task calls "suspend my processes until the operator mounts the
tape", it's hard to guess whether you want the other threads running or
not.

In UNIX-land it can be pretty easy to guess. Making such guesses
portable could be problematic. Providing a list of what OS calls will
block all threads is probably about as close as you can come, but that
wouldn't have solved the original problem, since the I/O that blocked
your code would have just been on that list.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
      Remember, drive defensively if you drink.