> Is code like this safe in the C++1 Unordered model? > Thread 1: > int x = obj->v; > obj->Release(); > Thread 2: > obj->Release(); > where obj's destructor trashes obj->v. > The potential hazard is if thread 1's obj->Release() atomic decrement is > reordered to run before the obj->v load has completed, then Thread 2's > obj->Release() runs and trashes obj->v, and thread 1 reads the trashed > value.
Indeed, but note that you don't need a full barrier on release; a barrier which prevents instructions from being moved down below the release is sufficient. (The general rule is that you can move an instruction into a critical section, but not out of one.) > For what it's worth, I think asking programmers to even think about such > question is insane, so I'd go for full memory barriers and sequential > consistency until we have benchmark numbers showing big wins from other > choices. I totally agree, but I think it /might/ be sane to make addref unordered and release a partial barrier as described above. FWIW, I once tried changing all of our atomic string refcounting to non-atomic operations and could not eke out a performance (or stability) difference on x64. This was despite the fact that I was able to generate profiles where the atomic string refcounting showed up as taking a few percentage points. I think bz reproduced this somewhat surprising result more recently. Of course that says nothing about ARM, or about our other atomic addrefs. And really, I still don't entirely believe the correctness of my result in those tests. -Justin _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
