Is there an official statement somewhere about the memory model assumptions for using TBB? In the reference manual (version 1.8), fences are mentioned only in "6.2 atomic
Before replying to this, make sure you look up "volatile" in the forum and are aware of the issues (it basically doesn't work, as is already acknowledged by the TBB project; my concern is that any code using it betrays that it might be sticking its head in the sand concerning a data race, so you basically wouldn't want to see "volatile" anywhere in TBB except in some platform-specific code). For the memory (consistency) model, some more reading is probably required.
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.