Liste des Groupes | Revenir à c arch |
However... There is "special" mutex logic that actually requires a #StoreLoad! Peterson's algorithm for example. Iirc, it needs a #StoreLoad because it depends on a store followed by a load to another location to hold true. This is a bit different than other locking algorithms...The folly library hazard pointers use that on windows, membarrier() system call on linux (something else on older linuxes), to get rid of the expensive store/load memory barrier in hazard pointer loads. Something like 0.7 nsecs w/o membar vs 7.7 w/ membar. The term I've seen being used now is asymmetric memory barrier.
There there are more "exotic" methods such as so-called asymmetric mutexes. They can have fast paths and slow paths, so to speak. It's almost getting into the realm of RCU here... A fast path can be memory barrier free. The slow path can make things consistent with the use of so called "remote" memory barriers. It's funny that Windows seems to have one:
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
;^)
The slow path is meant to not be frequently used, hence the term asymmetric. On par with read/write logic... :^)
Les messages affichés proviennent d'usenet.