Re: Assignment with Adjust and Task Safety

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

On 2016-03-22 15:36, Jeremiah wrote:
> I've been playing around with shared/safe/smart pointer
> representations in Ada and have been trying to wrap my head around how
> task safety works with Adjustment. I definitely get the concept of
> Atomic increment/decrement in order to allow to shared pointers in two
> separate task to work safely, but when two separate tasks work on the
> same shared pointer, I am having trouble using atomic
> increment/decrement to prevent the following issue:
>
> Initial conditions:
> 1.  Task_A and Task_B both have access to Shared_Pointer_A
> 2.  Shared_Pointer_A currently is the only reference to Object_A (count = 1)
> 3. Shared_Pointer_B currently points to a different Object_B (count
> =  1 or whatever). Additionally, Shared_Pointer_B is only used by Task_B.
> 4.  Shared_Ponter_C is currently null and only used by Task_A
>
> If I start an assignment in Task_A of Shared_Pointer_C :=
> Shared_Pointer_A, but get interrupted by Task_B in between when the
> contents of Shared_Pointer_A are copied into Shared_Pointer_C and when
> Shared_Pointer_C is adjusted, if Task_B then does the assignment
> Shared_Pointer_A := Shared_Pointer_B, how do I prevent Shared_Pointer_C
>from working with a reference that is finalized by Task_B's assignment
> process?

You cannot share mutable smart pointer. There is no way to keep it 
consistent.

> I don't think atomic increment/decrement will fix this as the task
> switch happens outside of both Adjust and Finalize. Is there some other
> way to prevent this? I know at the higher level I can wrap
> Shared_Pointer_A into a protected type to ensure the assignments and
> reads from it are protected, but that is something normally out of the
> scope of the Shared_Pointer_Type.

You add a mutex, global or of a narrower scope, and take it in Adjust 
and Finalize before doing anything else with the pointer.

I don't do this in my implementation of smart pointers because I 
consider it not worth the overhead of two protected actions for being 
protected against concurrent access to the pointer. [*]

The rationale is this. Smart pointers are unlikely shared. Normally they 
are kept in containers that are not shared or else are protected by a 
mutex, which eliminates the problem.

Yes, it is a potentially a very dangerous problem. It would be great if 
a tool like AdaControl could detect it. I hope J-P will comment on this.

-------------------
* You cannot wrap a protected object by the smart pointer because that 
would mean calling target object Finalization on the context of a 
protected operation, which is highly undesirable.

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