Martin Devera schrieb: > I measured it. Lock op in futex based linux locking is of the same > speed as windows critical section and it is about 30 cycles on my > P4 1.8GHz in uncontented case. > As explained in already mentioned http://www.linuxjournal.com/article/6993 > it seems due to pipeline flush during cmpxchg insn. > And there will be cacheline transfer penalty which is much larger. So > that mutex locking will take time comparable with protected code itself > (assuming fast code like dict/list read). > Single compare will take ten times less. > Am I missing something ? I'll have to wait for your revised algorithm, but likely, you will need some kind of memory barrier also, or else it can't work in the multi-processor case. In any case, if to judge whether 30 cycles is few or little, measurements of the alternative approach are necessary. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4