Re: Multitasking and containers

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

On Fri, 24 Nov 2006 11:35:11 +0100, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>>> Paragraph 3 in Annex A says that it's OK to call any standard subprogram 
>>> from concurrent tasks as long as the parameters do not overlap. John 
>>> Barnes ("Progamming in Ada 2005") suggests that in order to (for 
>>> example) read from the same container, the operations need to be 
>>> protected "by using the normal techniques such as protected objects".
>>>
>>> But reading from the protected object is not mutually exclusive (many 
>>> readers are allowed) - so where's the gain? What's the difference 
>>> between concurrent reads of, say, a Vector via protected object vs. 
>>> direct access?
>> 
>> I think he didn't mean container being a protected object.
> 
> No, but you might want to encapsulate a container within a protected 
> object and have some protected procedures and functions forwarding to 
> relevant ones in the container.

OK, but that's same to me. Aggregation + delegation = inheritance for
poor...

>> [ I don't know if ARM 2005 permits mutable implementations of read
>> operations on the containers. I suppose it does, so the need to lock upon
>> read. ]
> 
> That would be interesting, but would break apart when encapsulated 
> within a protected object, because there multiple readers would be allowed.
> 
> Having a mutex for readers sounds like a concurrency killer and relying 
> on protected wrappers seems to be fragile because of this possible 
> mutability. So - what is The Solution (tm) for multiple tasks reading 
> from the same container?
> 
> Let's say you want to have N worker tasks consulting a shared dictionary 
> (map) that was initialized before the tasks started their work. How 
> would you solve this?

I would try to decouple the mutable part. [ It is a quite common problem,
not necessarily in the context of concurrent programming. ] The cache that
does not belong to the container should be associated with the caller's
task. That would eliminate any need of locking. The cache shared between
the callers should be locked when changed. So a protected object should be
associated with that cache, not with the container as a whole.

Write your own container. Parallel systems require delicate handmade work.

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