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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newsfeeder.wxs.nl!feeder.enertel.nl!nntpfeed-01.ops.asmr-01.energis-idc.net!feeder.xsnews.nl!feeder.news-service.com!post.news-service.com!news1.surfino.com!not-for-mail Message-Id: <1776861.Inq2IMonX4@linux1.krischik.com> From: Martin Krischik Subject: Rendezvous based mutithreading. Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime Reply-To: martin@krischik.com Date: Fri, 25 Mar 2005 13:42:31 +0100 References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <1111607633.301232.62490@z14g2000cwz.googlegroups.com> <4241e04c$0$11471$9b4e6d93@newsread2.arcor-online.net> <1111614619.83944@athnrd02> <3895971.bl8ACDBTNI@linux1.krischik.com> <1111721265.519102@athnrd02> Organization: None User-Agent: KNode/0.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: abuse@surfino.com NNTP-Posting-Host: 83.169.175.19 (83.169.175.19) NNTP-Posting-Date: Fri, 25 Mar 2005 14:00:18 +0100 X-Trace: 4ac1142440b62f60c0ab604532 Xref: g2news1.google.com comp.lang.ada:9981 comp.lang.c++:47215 comp.realtime:1717 Date: 2005-03-25T13:42:31+01:00 List-Id: Ioannis Vranos wrote: > --->> At first, in this and other messages you had set the follow-ups to > --->> comp.lang.ada which means we can not follow the discussion > --->> anymore!] Sorry about that. Knode is a bit restrictive on cross posts. > Martin Krischik wrote: > > > Yes, and process/system boundaries when Annex E is implemented. > > ISO C++ defines no threading facilities so far (but *care has been > taken* to be easy implementing the algorithms and container operations > as thread-safe). > > The only multithreading I know is the .NET lock-based multithreading. I > can't understand how in such an environment you can expect to catch > exceptions reliably. I can only assume that Ada's built in > multithreading mechanism is not lock-based. Ada has two multithreading paradigms implemented. There are protected types which are lock based (but you don't start new threads with them) and task types which are rendezvous based (these are the types which actualy start new threads): http://en.wikibooks.org/wiki/Programming:Ada:Tasking In rendezvous based mutitheading two task meet at rendezvous points (hence the name). An exeptions happening inside a rendezvous points need to be handled by both theads participating at the redevous. Also: expections happening inside the "contructor" (C++ talk - the Ada terms are different) of an task type need to be handeled by the originating thread. Reason: the newly created thread is ready the handle exeptions since it is only in its contruction phase. At first I it was quite difficult for me to understand rendezvous based multithreading - I was only used to lock based multithreading from C (OS/2) C++ (OCL) and Java (java threads). But once I understand how it works I found it far easier to use and more stable in respect of dead locks. It also works with all all operating system I know of. But I think it would be quite a challenge to create rendezvous based multithreading on top of C++ templates - and yet keep it easy to use for the programmer. With Regards Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com