f69fea64e0
Right now we're using a DWCAS to atomically set the running_mask while being constrained by the thread_mask. This DWCAS is annoying because we may seriously need it later when adding support for thread groups, for checking that the running_mask applies to the correct group. It turns out that the DWCAS is not strictly necessary because we never need it to set the thread_mask based on the running_mask, only the other way around. And in fact, the running_mask is always cleared alone, and the thread_mask is changed alone as well. The running_mask is only relevant to indicate a takeover when the thread_mask matches it. Any bit set in running and not present in thread_mask indicates a transition in progress. As such, it is possible to re-arrange this by using a regular CAS around a consistency check between running_mask and thread_mask in fd_update_events and by making a CAS on running_mask then an atomic store on the thread_mask in fd_takeover(). The only other case is fd_delete() but that one already sets the running_mask before clearing the thread_mask, which is compatible with the consistency check above. This change has happily survived 10 billion takeovers on a 16-thread machine at 800k requests/s. The fd-migration doc was updated to reflect this change. |
||
|---|---|---|
| .. | ||
| design-thoughts | ||
| internals | ||
| lua-api | ||
| 51Degrees-device-detection.txt | ||
| DeviceAtlas-device-detection.txt | ||
| SOCKS4.protocol.txt | ||
| SPOE.txt | ||
| WURFL-device-detection.txt | ||
| acl.fig | ||
| architecture.txt | ||
| close-options.txt | ||
| coding-style.txt | ||
| configuration.txt | ||
| cookie-options.txt | ||
| gpl.txt | ||
| haproxy.1 | ||
| intro.txt | ||
| lgpl.txt | ||
| linux-syn-cookies.txt | ||
| lua.txt | ||
| management.txt | ||
| netscaler-client-ip-insertion-protocol.txt | ||
| network-namespaces.txt | ||
| peers-v2.0.txt | ||
| peers.txt | ||
| proxy-protocol.txt | ||
| queuing.fig | ||
| regression-testing.txt | ||
| seamless_reload.txt | ||