global interpreter lock

[Mike Meyer]

Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:
> On Wed, 31 Aug 2005 22:44:06 -0400, Mike Meyer <mwm at mired.org> declaimed
> the following in comp.lang.python:
>> I don't know what Ada offers. Java gives you pseudo-monitors. I'm
>
> 	From the days of mil-std 1815, Ada has supported "tasks" which
> communicate via "rendezvous"... The receiving task waits on an "accept"
> statement (simplified -- there is a means to wait on multiple different
> accepts, and/or time-out). The "sending" task calls the "entry" (looks
> like a regular procedure call with in and/or out parameters -- matches
> the signature of the waiting "accept"). As with "accept", there are
> selective entry calls, wherein which ever task is waiting on the
> matching accept will be invoked. During the rendezvous, the "sending"
> task blocks until the "receiving" task exits the "accept" block -- at
> which point both tasks may proceed concurrently.

Thank you for providing the description. That was sufficient context
that Google found the GNAT documentation, which was very detailed.

Based on that, it seems that entry/accept are just a synchronization
construct - with some RPC semantics thrown in.

> 	As you might notice -- data can go both ways: in at the top of the
> rendezvous, and out at the end.
>
> 	Tasks are created by declaring them (there are also task types, so
> one can easily create a slew of identical tasks). 
>
> procedure xyz is
>
> 	a : task;		-- not real Ada, again, simplified
> 	b : task;
>
> begin		-- the tasks begin execution here
> 	-- do stuff in the procedure itself, maybe call task entries
> end;

The problem is that this doesn't really provide any extra protection
for the programmer. You get language facilities that will provide the
protection, but the programmer has to remember to use them in every
case. If you forget to declare a method as protected, then nothing
stops two tasks from entering it and screwing up the objects data with
unsynchronized access. This should be compared to SCOOP, where trying
to do something like that is impossible.

       Thanks again,
       <mike

-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.