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.
prev parent 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