Re: Multitasking and containers

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
.

Relevant Pages

  • Re: GNAT for MS Visual Studio
    ... Consider a container inside the protected object. ... presumably has access variables to actual contained objects (to ... If the target objects are considered to be OUTside of the protected ...
    (comp.lang.ada)
  • Re: Multitasking and containers
    ... from concurrent tasks as long as the parameters do not overlap. ... protected "by using the normal techniques such as protected objects". ... But reading from the protected object is not mutually exclusive (many ... I think he didn't mean container being a protected object. ...
    (comp.lang.ada)
  • Re: Multitasking and containers
    ... John Barnes suggests that in order to 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 - so where's the gain? ... What's the difference between concurrent reads of, say, a Vector via protected object vs. direct access? ... That would be interesting, but would break apart when encapsulated within a protected object, because there multiple readers would be allowed. ...
    (comp.lang.ada)
  • Re: Multitasking and containers
    ... But I think that's true only when multiple readers are calling protected ... protected procedure when manipulating a container nested inside a protected ... Declare the container object inside a protected object, ... long as you use protected procedures, ...
    (comp.lang.ada)
  • Lazy container
    ... the container pulls items on the fly from an unspecified source through a function and returns an instance of a given class over the pulled item. ... The problem with this implementation is that the cache never decreases in length as Foo instances are no longer referenced by the lc accessor since they're all referenced by the internal cache. ...
    (comp.lang.python)