comp.lang.ada
 help / color / mirror / Atom feed
From: Brad Moore <brad.moore@shaw.ca>
Subject: Re: Termination of tasks waiting on a protected queue
Date: Tue, 27 May 2014 19:04:50 -0600
Date: 2014-05-27T19:04:50-06:00	[thread overview]
Message-ID: <TCahv.2070694$Sa5.515012@fx19.iad> (raw)
In-Reply-To: <91780287-64c4-48e4-8cb1-89909b5d59f9@googlegroups.com>

On 14-05-27 05:08 AM, Alejandro R. Mosteo wrote:
> On Monday, May 19, 2014 1:05:59 AM UTC+2, Brad Moore wrote:
>> On 14-05-18 01:32 AM, Natasha Kerensikova wrote:
>>
>>> The problem is, how to terminate cleanly the worker tasks in a
>>
>>> non-Ravenscar environment when the main application is completed?
>>
>>>
>>
>>>   From my understanding of ARM 9.3, I need a terminate alternative in the
>>
>>> worker tasks. But those can only exist in selective accepts, so I have
>>
>>> to turn things around and make the task wait for one of its entries to
>>
>>> be called, rather than wait for an external protected entry.
>>
>>>
>>
>>> But then, how can a worker task entry be used to solve my problem? A
>>
>>> protected operation cannot call a task entry, because it's potentially
>>
>>> blocking. The job generator cannot call the entry directly, because it
>>
>>> would block when the task is not ready, so I still need a queue between
>>
>>> the generator and the worker task.
>>
>>
>>
>> A protected entry can however requeue to a task entry.
>>
>>
>> I did not want the programmer to have to call some protected subprogram
>>
>> to trigger the task pool to terminate.
>
> Could an atomic boolean be used to avoid a protected object? Given that after it being set it wouldn't be unset, and there's no race condition, I wonder.
>

The problem is not the protected subprogram. It is having to force the
programmer to explicitly specify somewhere in the code a trigger to 
initiate the destruction of the task pool, whether via a protected 
object or setting an atomic boolean, or some other means.

Setting the trigger before the main task exits for instance, is error 
prone because there may be other tasks executing that might still want 
to use the task pool.

Using the mechanism I suggested means the task pool does not get 
destroyed until all tasks have completed, since the main task wont exit 
until all other tasks have either completed or are waiting on a select 
statement with a Terminate alternative.


      reply	other threads:[~2014-05-28  1:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-18  7:32 Termination of tasks waiting on a protected queue Natasha Kerensikova
2014-05-18  9:24 ` anon
2014-05-18 19:43   ` Natasha Kerensikova
2014-05-18 17:16 ` Jeffrey Carter
2014-05-18 19:54   ` Natasha Kerensikova
2014-05-18 21:54     ` Jeffrey Carter
2014-05-18 18:42 ` sbelmont700
2014-05-18 18:48   ` Jeffrey Carter
2014-05-18 20:51     ` sbelmont700
2014-05-18 21:44       ` Jeffrey Carter
2014-05-19 21:49   ` Randy Brukardt
2014-05-20  7:54     ` Dmitry A. Kazakov
2014-05-20  7:58       ` Dmitry A. Kazakov
2014-05-18 23:05 ` Brad Moore
2014-05-19  7:28   ` Natasha Kerensikova
2014-05-27 11:08   ` Alejandro R. Mosteo
2014-05-28  1:04     ` Brad Moore [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox