Task safe containers? Help needed.

Task safe containers? Help needed.

[reinert]

Hi,

if I want to access a container (Vector, Set, Map) by several tasks (updating and reading) - (hopefully) without loosing functionality of the container.

What should I do?

reinert

Re: Task safe containers? Help needed.

[Niklas Holsti]

On 17-10-08 07:27 , reinert wrote:
> Hi,
>
> if I want to access a container (Vector, Set, Map) by several tasks
> (updating and reading) - (hopefully) without loosing functionality of
> the container.
>
> What should I do?
>
> reinert

Wrap the container in a protected object so that all container
operations are executed by one task at a time.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Task safe containers? Help needed.

[Dmitry A. Kazakov]

On 2017-10-08 06:27, reinert wrote:

> if I want to access a container (Vector, Set, Map) by several tasks
> (updating and reading) - (hopefully) without loosing functionality of
> the container.
> 
> What should I do?

1. If operations are short and non-blocking put the container in a 
protected object and route operations trough object's ones.

2. If operations are long, unbounded, blocking (most of the cases):

2.a Use a mutex taken at the beginning of each operation and released at 
the end.

2.b Use monitor task owning the container. All operations are performed 
by the task from task's entries.

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

Re: Task safe containers? Help needed.

[reinert]

About your first option: Putting the containers in a protected object makes the container functions "private" and not directly available outside the protected object. Right? I like these container functions.

But your other options also somehow complicates :-)

A compromise seems to be necessary :-) Maybe the first option anyway facilitates cleanest code? There must be a reason for the invention of protected types.

reinert

On Sunday, October 8, 2017 at 8:57:18 AM UTC+2, Dmitry A. Kazakov wrote:
> On 2017-10-08 06:27, reinert wrote:
> 
> > if I want to access a container (Vector, Set, Map) by several tasks
> > (updating and reading) - (hopefully) without loosing functionality of
> > the container.
> > 
> > What should I do?
> 
> 1. If operations are short and non-blocking put the container in a 
> protected object and route operations trough object's ones.
> 
> 2. If operations are long, unbounded, blocking (most of the cases):
> 
> 2.a Use a mutex taken at the beginning of each operation and released at 
> the end.
> 
> 2.b Use monitor task owning the container. All operations are performed 
> by the task from task's entries.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Re: Task safe containers? Help needed.

[Dmitry A. Kazakov]

On 2017-10-08 17:10, reinert wrote:

> About your first option: Putting the containers in a protected
> object  makes the container functions "private" and not directly available
> outside the protected object. Right?

Which is good, since they are unsafe.

> But your other options also somehow complicates :-)

Not at all.

> A compromise seems to be necessary :-)

There is no compromise, each method has its use.

> Maybe the first option anyway
> facilitates cleanest code?

No. The cleanest code would be per delegation. Ada has none. Then there 
are issues with interface functions while most relevant synchronization 
mechanisms considered mutating. The Rosen's trick is used to work that 
around. A problem for monitor (#2.b) is to have an unconstrained result, 
since task entries cannot return such.

> There must be a reason for the invention of
> protected types.

The reason was to add an OO view on synchronization as a complement to 
the procedural view tasks offer.

The implementation provided by protected objects was chosen to be most 
efficient, powerful, safe, verifiable and universal. Which comes with 
certain limitations.

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

Re: Task safe containers? Help needed.

[reinert]

Thanks, will test out options...

reinert

On Sunday, October 8, 2017 at 6:05:04 PM UTC+2, Dmitry A. Kazakov wrote:
> On 2017-10-08 17:10, reinert wrote:
> 
> > About your first option: Putting the containers in a protected
> > object  makes the container functions "private" and not directly available
> > outside the protected object. Right?
> 
> Which is good, since they are unsafe.
> 
> > But your other options also somehow complicates :-)
> 
> Not at all.
> 
> > A compromise seems to be necessary :-)
> 
> There is no compromise, each method has its use.
> 
> > Maybe the first option anyway
> > facilitates cleanest code?
> 
> No. The cleanest code would be per delegation. Ada has none. Then there 
> are issues with interface functions while most relevant synchronization 
> mechanisms considered mutating. The Rosen's trick is used to work that 
> around. A problem for monitor (#2.b) is to have an unconstrained result, 
> since task entries cannot return such.
> 
> > There must be a reason for the invention of
> > protected types.
> 
> The reason was to add an OO view on synchronization as a complement to 
> the procedural view tasks offer.
> 
> The implementation provided by protected objects was chosen to be most 
> efficient, powerful, safe, verifiable and universal. Which comes with 
> certain limitations.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Re: Task safe containers? Help needed.

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:orci8c$mpl$1@gioia.aioe.org...
> On 2017-10-08 06:27, reinert wrote:
>
>> if I want to access a container (Vector, Set, Map) by several tasks
>> (updating and reading) - (hopefully) without loosing functionality of
>> the container.
>>
>> What should I do?
>
> 1. If operations are short and non-blocking put the container in a 
> protected object and route operations trough object's ones.

If some of the operations are functions, and you have an up-to-date 
compiler, then use aspect Exclusive_Functions so that the mutual exclusion 
extends to the functions as well as the procedures in the protected object. 
Otherwise, functions aren't *officially* exclusive, so you have to use all 
procedures for proper exclusion. (Note: I'm not aware of any Ada compiler 
that actually allows non-exclusive functions, but the possibility exists 
unless you use the aspect.)

                                       Randy.

Re: Task safe containers? Help needed.

[Dmitry A. Kazakov]

On 09/10/2017 23:54, Randy Brukardt wrote:

> If some of the operations are functions, and you have an up-to-date
> compiler, then use aspect Exclusive_Functions so that the mutual exclusion
> extends to the functions as well as the procedures in the protected object.

Interesting.

BTW, if protected types were declared as a normal types without ugly 
C++-ish brackets, then we could simply have it passed in-out mode. 
Functions are now allowed to have this. Or it could be passed as a 
non-constant anonymous access. Both would naturally imply 
"update-exclusion", no aspect ever needed.

> Otherwise, functions aren't *officially* exclusive, so you have to use all
> procedures for proper exclusion.

I see it as an advantage, actually. A mutex-based solution could deploy 
read-write mutex to achieve the same effect. Functions would take mutext 
in the read-only mode. Procedures would use the full-access mode.

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

Re: Task safe containers? Help needed.

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:orhslu$pji$1@gioia.aioe.org...
> On 09/10/2017 23:54, Randy Brukardt wrote:
>
>> If some of the operations are functions, and you have an up-to-date
>> compiler, then use aspect Exclusive_Functions so that the mutual 
>> exclusion
>> extends to the functions as well as the procedures in the protected 
>> object.
>
> Interesting.
>
> BTW, if protected types were declared as a normal types without ugly 
> C++-ish brackets, then we could simply have it passed in-out mode. 
> Functions are now allowed to have this. Or it could be passed as a 
> non-constant anonymous access. Both would naturally imply 
> "update-exclusion", no aspect ever needed.

I agree that the function/procedure definition was a bad idea: only 2 of the 
4 possibilities are supported, and all of the can make sense. Too late to 
fix, though.

Also note that you might need exclusion for read-only access (that's 
definitely true in Ada 2005/2012 where there are no guarantee of task safety 
even for reading of a container -- Ada 2020 will change this slightly).

                               Randy.