4 ms·
According to the paper for their queue: http://www.cs.rochester.edu/u/scott/papers/1996_PODC_queues.pdf http://www.cs.rochester.edu/u/scott/papers/1996_PODC_qu
by martincmartin 16y ago
According to the paper for their queue:
http://www.cs.rochester.edu/u/scott/papers/1996_PODC_queues.pdf http://www.cs.rochester.edu/u/scott/papers/1996_PODC_queues....
It uses either compare_and_swap or load_linked/store_conditional. I thought compare_and_swap had a horrible (i.e. very slow) implementation on x86. Any idea whether load_linked/store_conditional is any better?
- papaf 16y agoThe java JDK lockless queue is also compare and swap. I don't know the reasoning behind it though.
- dumael 16y agoCAS is slow because it acts as a serializing instruction. If you depend on success or fail the instructions after it have to wait until it has been resolved. Also, the update has to be pushed out to the cache at least. So yes, slow but otherwise it would be of no use. load_linked and store_conditional are not much better. Depending on implementation they can spuriously fail because something poked the cache, there was memory traffic etc.
- jasonwatkinspdx 16y agoHow can one implement a lock on x86 without cas/ll-sc? Lamport's Bakery?
- lzimm 16y agoso zen: cas slow, locks slower.
- liblfds-admin 16y agoCAS on platforms which provide CAS for lock-free (x86/x64), LL/SC on platforms which provide LL/SC for lock-free (ARM). AFAIK, platforms provide one or the other; not both. So you have to use what you're given.