It may be tedious to find all the uses of a shared
variable in a task's dynamic extent, but at least it is relatively
straightforward. The situation is much worse when the Dependencies tool reports
that you have a sharing problem on a pointer dereference. In general:
A dereference of a pointer expression may or may
not refer to the same object as some other dereference of a pointer expression
with the same type.
Different executions of a pointer expression
dereference may or may not refer to the same object.
If you have a variable whose address is taken, a
dereference of a pointer expression may or may not refer to that variable.
However, suppose that your program has an abstract
data type whose objects are implemented as dynamically allocated data
structures. You may be able to step back from the individual pointer
dereferences involved in a sharing problem and say: "These are just
implementation details in an access to an abstract object." If you can prove
that the access pattern for the abstract object satisfies the incidental
sharing pattern, you can apply the techniques from this topic:
Within the task, create a private object of the
abstract data type.
Make a reference to the private object available
throughout the task.
Replace references to the original object with
references to the private object.
Destroy the private object before the task exits.
The point is to ignore the pointer dereferences, and
solve the problem in terms of the abstraction that they are implementing.