Re: Class with task destructor

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 2 Dec 2011 08:20:43 -0800 (PST), Adam Beneschan wrote:

> On Dec 1, 9:30�pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
> wrote:
>> On 12/01/2011 05:50 PM, Randy Brukardt wrote:
>>
>>> In any case, what a particular target can do is not that relevant to what
>>> the language design can do. Ada 95 tried to add a multi-way entry call, and
>>> every implementer who studied it ended up reporting that the implementation
>>> would essentially end up being some form of polling. Which is not what
>>> anyone was hoping for. It got dropped from Ada 95.
>>
>> Ada 95 did add asynchronous transfer of control, which does allow an entry call
>> as a trigger, and anything in the "then abort" part, including an entry call:
>>
>> select
>> � � Entry_Call_1;
>> then abort
>> � � Entry_Call_2;
>> end select;
>>
>> These can be nested as deeply as desired, so it seems that Ada 95 did
>> effectively add a multi-way entry call.
> 
> It's not entirely the same, though.  In a multi-way entry, if entry
> Entry_Call_2 becomes available first, then that entry is accepted and
> Entry_Call_1 can no longer be accepted.
> above, if Entry_Call_2 is accepted first, but Entry_Call_1 becomes
> available before the Entry_Call_2 entry is completed, I believe that
> Entry_Call_1 is accepted and an attempt is made to cancel the call to
> Entry_Call_2--which probably doesn't succeed unless a requeue is
> involved, so that the Entry_Call_2 rendezvous still completes, but the
> Entry_Call_1 rendezvous also takes place.  I'm not 100% sure I have
> the semantics right, but I'm pretty sure the behavior would be
> different from a true multi-way entry.

I am uncomfortable with the semantics that allows aborting a rendezvous. It
is also unclear what happens when Entry_Call_1 re-queues without about. I
guess that should not be abortable. 

That was the "ANY" entry call. There also exists "ALL" entries call. That
is when the task engages a rendezvous with multiple tasks and/or executes
protected actions on multiple objects. E.g.

1. it awaits entries of all specified tasks and/or barriers of the
protected objects' entries;

2. the tasks are blocked and/or protected actions are started;

3. entries are executed in an unspecified order;

4. tasks are released and/or protected actions are completed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de