Re: Safety of unprotected concurrent operations on constant objects

[Brad Moore <brad.moore@shaw.ca>]

On 04/05/2014 9:57 AM, Natasha Kerensikova wrote:
> On 2014-05-04, sbelmont700@gmail.com <sbelmont700@gmail.com> wrote:
>> On Sunday, May 4, 2014 3:46:00 AM UTC-4, Natasha Kerensikova wrote:
>>>
>>> So I guess to correctly frame it as a question, that would be: how can I
>>>
>>> have a map capable of concurrent reads with minimal wheel reinvention?
>>>
>>
>> You really can't.  You can either reinvent the wheel in your own
>> task-safe manner,
>
> I find it extremely hard to believe that there is no such wheel existing
> out there. Standard containers and Booch components might not fit the
> particular requirements, but I would bet there are some existing container
> implementations that fit.

I believe as long as the use of the container involves only read 
operations (functions with in parameters), it should be safe to use 
concurrently. Yes, these read operations typically involve modifying the 
container (to implement tamper checking), but is done in such a
way to allow safe concurrent access (at least in the implementations I 
have tried).

If done carefully, concurrent write operations on a container are also 
possible.
For example, I can provide an example in GNAT of incrementing all 
elements in an integer vector container with parallel execution, without 
any added protection or synchronization. Each worker is only updating 
elements in its assigned range of the vector, via Replace_Element. In 
the GNAT implementation, Replace_Element doesn't
set any tampering flags. It only checks for tampering, which might 
happen if another call such as Iterate was executed concurrently.
Since the only call happening during the parallel execution is 
Replace_Element, it works.

That being said, I didn't have any luck finding wording in the RM that
guarantees safe concurrent use of a constant object of a 
language-defined container object. While it likely is safe to do so, if you
are looking for a guarantee, the RM does not appear to provide one 
currently. It might be that this clarification could be added to the RM 
relatively easily, provided that implementers agree that such a 
clarification wouldn't cause too much of an implementation burden.


>
>> or assume-the-worst about the standard map and surround it with a
>> mutex.  Though, as was said, the split-seconds you would burn on the
>> mutex would be negligible when compared to the network delay of
>> supplying the results.
>
> How would you "surround it with a mutex"? Do you mean a procedure in a
> procted object, or some other scheme I'm not familiar with?
>
> However, if I start assuming the worst about standard containers, I
> might soon slip down the slope towards assuming the worst about all
> others standard features. There is nothing in the ARM that prevents tag
> checks or dispatching from being implemented through a splay tree or
> some other concurrent-read-unsafe mechanism, is there? Should I mutex
> those too then?
>