86c6a9221a
Given that a "count" value of 32M was seen in _shctx_wait4lock(), it is very important to prevent this from happening again. It's absolutely essential to prevent the value from growing unbounded because with an increase of the number of threads, the number of successive failed attempts will necessarily grow. Instead now we're scanning all 2^p-1 values from 3 to 255 and are bounding to count to 255 so that in the worst case each thread tries an xchg every 255 failed read attempts. That's one every 4 on average per thread when there are 64 threads, which corresponds to the initial count of 4 for the first attempt so it seems like a reasonable value to keep a low latency. The bug was introduced with the shctx entries in 1.5 so the fix must be backported to all versions. Before 1.8 the function was called _shared_context_wait4lock() and was in shctx.c. |
||
|---|---|---|
| .. | ||
| common | ||
| import | ||
| proto | ||
| types | ||