* rendez-vous underlying mechanism @ 2002-03-25 13:48 Bozo 2002-03-25 20:09 ` Marin David Condic ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Bozo @ 2002-03-25 13:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-25 13:48 rendez-vous underlying mechanism Bozo @ 2002-03-25 20:09 ` Marin David Condic 2002-03-26 1:44 ` Adrian Hoe 2002-03-26 10:58 ` Bozo 2 siblings, 0 replies; 26+ messages in thread From: Marin David Condic @ 2002-03-25 20:09 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-25 13:48 rendez-vous underlying mechanism Bozo 2002-03-25 20:09 ` Marin David Condic @ 2002-03-26 1:44 ` Adrian Hoe 2002-03-26 1:16 ` Jeffrey Creem ` (2 more replies) 2002-03-26 10:58 ` Bozo 2 siblings, 3 replies; 26+ messages in thread From: Adrian Hoe @ 2002-03-26 1:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 1:44 ` Adrian Hoe @ 2002-03-26 1:16 ` Jeffrey Creem 2002-03-26 2:05 ` Adrian Hoe 2002-03-26 6:04 ` Simon Wright 2 siblings, 0 replies; 26+ messages in thread From: Jeffrey Creem @ 2002-03-26 1:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 1:44 ` Adrian Hoe 2002-03-26 1:16 ` Jeffrey Creem @ 2002-03-26 2:05 ` Adrian Hoe 2002-03-26 2:16 ` Jeffrey Creem 2002-03-26 6:04 ` Simon Wright 2 siblings, 1 reply; 26+ messages in thread From: Adrian Hoe @ 2002-03-26 2:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 2:05 ` Adrian Hoe @ 2002-03-26 2:16 ` Jeffrey Creem 0 siblings, 0 replies; 26+ messages in thread From: Jeffrey Creem @ 2002-03-26 2:16 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 1:44 ` Adrian Hoe 2002-03-26 1:16 ` Jeffrey Creem 2002-03-26 2:05 ` Adrian Hoe @ 2002-03-26 6:04 ` Simon Wright 2002-03-26 10:17 ` Adrian Hoe [not found] ` <a8olf7$enj$3@nntp9.atl.mindspring.net> 2 siblings, 2 replies; 26+ messages in thread From: Simon Wright @ 2002-03-26 6:04 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 6:04 ` Simon Wright @ 2002-03-26 10:17 ` Adrian Hoe 2002-03-26 9:31 ` tgingold ` (2 more replies) [not found] ` <a8olf7$enj$3@nntp9.atl.mindspring.net> 1 sibling, 3 replies; 26+ messages in thread From: Adrian Hoe @ 2002-03-26 10:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 10:17 ` Adrian Hoe @ 2002-03-26 9:31 ` tgingold 2002-03-26 10:40 ` David C. Hoos, Sr. 2002-03-27 1:42 ` Adrian Hoe 2 siblings, 0 replies; 26+ messages in thread From: tgingold @ 2002-03-26 9:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 10:17 ` Adrian Hoe 2002-03-26 9:31 ` tgingold @ 2002-03-26 10:40 ` David C. Hoos, Sr. 2002-03-27 1:42 ` Adrian Hoe 2 siblings, 0 replies; 26+ messages in thread From: David C. Hoos, Sr. @ 2002-03-26 10:40 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 10:17 ` Adrian Hoe 2002-03-26 9:31 ` tgingold 2002-03-26 10:40 ` David C. Hoos, Sr. @ 2002-03-27 1:42 ` Adrian Hoe 2 siblings, 0 replies; 26+ messages in thread From: Adrian Hoe @ 2002-03-27 1:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <a8olf7$enj$3@nntp9.atl.mindspring.net>]
* Re: rendez-vous underlying mechanism [not found] ` <a8olf7$enj$3@nntp9.atl.mindspring.net> @ 2002-04-07 6:44 ` Pascal Obry 2002-04-08 7:48 ` Jean-Pierre Rosen 1 sibling, 0 replies; 26+ messages in thread From: Pascal Obry @ 2002-04-07 6:44 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism [not found] ` <a8olf7$enj$3@nntp9.atl.mindspring.net> 2002-04-07 6:44 ` Pascal Obry @ 2002-04-08 7:48 ` Jean-Pierre Rosen 1 sibling, 0 replies; 26+ messages in thread From: Jean-Pierre Rosen @ 2002-04-08 7:48 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-25 13:48 rendez-vous underlying mechanism Bozo 2002-03-25 20:09 ` Marin David Condic 2002-03-26 1:44 ` Adrian Hoe @ 2002-03-26 10:58 ` Bozo 2002-03-26 14:10 ` Marin David Condic 2002-03-26 14:57 ` Kevin Cline 2 siblings, 2 replies; 26+ messages in thread From: Bozo @ 2002-03-26 10:58 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 10:58 ` Bozo @ 2002-03-26 14:10 ` Marin David Condic 2002-03-26 14:57 ` Kevin Cline 1 sibling, 0 replies; 26+ messages in thread From: Marin David Condic @ 2002-03-26 14:10 UTC (permalink / raw) 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 > > > > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 10:58 ` Bozo 2002-03-26 14:10 ` Marin David Condic @ 2002-03-26 14:57 ` Kevin Cline 2002-03-28 5:20 ` Richard Riehle 1 sibling, 1 reply; 26+ messages in thread From: Kevin Cline @ 2002-03-26 14:57 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-26 14:57 ` Kevin Cline @ 2002-03-28 5:20 ` Richard Riehle 2002-03-28 15:44 ` Marin David Condic 2002-04-08 17:05 ` Kevin Cline 0 siblings, 2 replies; 26+ messages in thread From: Richard Riehle @ 2002-03-28 5:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-28 5:20 ` Richard Riehle @ 2002-03-28 15:44 ` Marin David Condic 2002-04-08 17:05 ` Kevin Cline 1 sibling, 0 replies; 26+ messages in thread From: Marin David Condic @ 2002-03-28 15:44 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-03-28 5:20 ` Richard Riehle 2002-03-28 15:44 ` Marin David Condic @ 2002-04-08 17:05 ` Kevin Cline 2002-04-10 7:49 ` Ole-Hjalmar Kristensen 2002-04-10 13:39 ` Pat Rogers 1 sibling, 2 replies; 26+ messages in thread From: Kevin Cline @ 2002-04-08 17:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-04-08 17:05 ` Kevin Cline @ 2002-04-10 7:49 ` Ole-Hjalmar Kristensen 2002-04-10 13:39 ` Pat Rogers 1 sibling, 0 replies; 26+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-10 7:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-04-08 17:05 ` Kevin Cline 2002-04-10 7:49 ` Ole-Hjalmar Kristensen @ 2002-04-10 13:39 ` Pat Rogers 2002-04-10 17:19 ` Kevin Cline 1 sibling, 1 reply; 26+ messages in thread From: Pat Rogers @ 2002-04-10 13:39 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-04-10 13:39 ` Pat Rogers @ 2002-04-10 17:19 ` Kevin Cline 2002-04-10 17:23 ` Pat Rogers 2002-04-10 17:58 ` Marin David Condic 0 siblings, 2 replies; 26+ messages in thread From: Kevin Cline @ 2002-04-10 17:19 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-04-10 17:19 ` Kevin Cline @ 2002-04-10 17:23 ` Pat Rogers 2002-04-11 11:52 ` Ole-Hjalmar Kristensen 2002-04-10 17:58 ` Marin David Condic 1 sibling, 1 reply; 26+ messages in thread From: Pat Rogers @ 2002-04-10 17:23 UTC (permalink / raw) "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". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-04-10 17:23 ` Pat Rogers @ 2002-04-11 11:52 ` Ole-Hjalmar Kristensen 2002-04-11 16:01 ` Darren New 0 siblings, 1 reply; 26+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-11 11:52 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-04-11 11:52 ` Ole-Hjalmar Kristensen @ 2002-04-11 16:01 ` Darren New 0 siblings, 0 replies; 26+ messages in thread From: Darren New @ 2002-04-11 16:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: rendez-vous underlying mechanism 2002-04-10 17:19 ` Kevin Cline 2002-04-10 17:23 ` Pat Rogers @ 2002-04-10 17:58 ` Marin David Condic 1 sibling, 0 replies; 26+ messages in thread From: Marin David Condic @ 2002-04-10 17:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2002-04-11 16:01 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-03-25 13:48 rendez-vous underlying mechanism Bozo 2002-03-25 20:09 ` Marin David Condic 2002-03-26 1:44 ` Adrian Hoe 2002-03-26 1:16 ` Jeffrey Creem 2002-03-26 2:05 ` Adrian Hoe 2002-03-26 2:16 ` Jeffrey Creem 2002-03-26 6:04 ` Simon Wright 2002-03-26 10:17 ` Adrian Hoe 2002-03-26 9:31 ` tgingold 2002-03-26 10:40 ` David C. Hoos, Sr. 2002-03-27 1:42 ` Adrian Hoe [not found] ` <a8olf7$enj$3@nntp9.atl.mindspring.net> 2002-04-07 6:44 ` Pascal Obry 2002-04-08 7:48 ` Jean-Pierre Rosen 2002-03-26 10:58 ` Bozo 2002-03-26 14:10 ` Marin David Condic 2002-03-26 14:57 ` Kevin Cline 2002-03-28 5:20 ` Richard Riehle 2002-03-28 15:44 ` Marin David Condic 2002-04-08 17:05 ` Kevin Cline 2002-04-10 7:49 ` Ole-Hjalmar Kristensen 2002-04-10 13:39 ` Pat Rogers 2002-04-10 17:19 ` Kevin Cline 2002-04-10 17:23 ` Pat Rogers 2002-04-11 11:52 ` Ole-Hjalmar Kristensen 2002-04-11 16:01 ` Darren New 2002-04-10 17:58 ` Marin David Condic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox