while my basic assessment is still that contention will not play a significant role given the expected real world usage scenario — when testing with tighter schedule and rather short jobs (500µs), some phases of massive contention can be observed, leading to significant slow-down of the test. The major problem seems to be that extended phases of contention will effectively cause several workers to remain in an active spinning-loop for multiple microseconds, while also permanently reading the atomic lock. Thus an adaptive scheme is introduced: after some repeated contention events, workers now throttle down by themselves, with polling delays increased with exponential stepping up to 2ms. This turns out to be surprisingly effective and completely removes any observed delays in the test setup. |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||