Re: Multitasking and containers

[Matthew Heaney <matthewjheaney@earthlink.net>]

Maciej Sobczak <no.spam@no.spam.com> writes:

> 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".

Right.


> 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?

The reason is a conflict between safety and flexibility, a conflict that was
resolved in favor of safety.

The container must set some internal state to indicate that Query_Element is
executing, in order to prevent you from doing things inside Query_Element that
would potentially destroy the element (such as Delete'ing it).

Even though Query_Element is technically a read-only operation, that's true
only in the logical sense, not the physical sense.  It doesn't look like
Query_Element modifies the container, but it really does modify the container,
to set some state that indicates a Query_Element is in progress.

Yes, it would seem as if it should be possible for multiple tasks to all be
reading from the container simultaneously.  But it's impossible to do that and
also satisfy the requirement that the container detect potentially harmful
manipulation of the container while Query_Element is executing.

So multiple tasks -- even tasks only calling (logically) read-only operations
-- cannot simultaneously call container operations without also synchronizing
the tasks, by wrapping the container inside a protected object, using a
critical section, etc.

-Matt