We're purging volatile as we go. Ideally, after the purge there should only be volatile in the machine-specific headers, andand inplaces where we want to force a read, butnot necessarilya fence (e.g. the first test in the test-and-(test-and-set) idiom). I've been thinking of adding a method atomic
TBB is targeted at an audience that ismore concerned about their subject matter than the nuances of memory fences, so for the most part we've assumed that fences are in the intuitively obvious spots. Obviously, "intuitively obvious" is insufficient for experts, and for such experts we should specify where fencesare guaranteedprecisely.
With respect to tasks and fences, I think the minimal fencine guarantee is that tasks should have is that if task A is a predecessor of task B, then when B runs, it sees any memory updates by A. And a thread that executes task::wait_for_all() should see any updates by any of the tasks it is waiting on. I'm fairly sure the current implementation delivers this independent of the underlying threading API, because the fences are explicit in the reference counting mechanism upon which waiting is implemented.