Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.pascal.misc > #696
| From | aminer <aminer@toto.net> |
|---|---|
| Newsgroups | comp.lang.pascal.misc |
| Subject | We have to be smart please |
| Date | 2014-04-13 19:09 -0700 |
| Organization | albasani.net |
| Message-ID | <lif5dv$ejb$3@news.albasani.net> (permalink) |
Hello, Look at the following concurrent FIFO queue that is Waitfree on the push() and lockfree on the pop()... http://pastebin.com/f72cc3cc1 I have studied it deeply and i think it has a weekness, i have asked myself why it's slower than my concurrent FIFO queue that i am using inside my scalable FIFO fair lock that is using a Ticket Spinlock on the push() side and no synchronization on the pop() side, since only one thread will call he Leave() method of my scalable FIFO fair lock, so the concurrent FIFO queue doesn't need to use synchronization on the pop() side, but here is the weakness of the above node based FIFO queue, when you will delete the CAS on the pop() side there will be still cache-lines transfers that will slow the pop(), here are the cache-lines transfers: the "cmptmp = m_tail" on the pop() side will incur a cache-line transfer the "node next = cmp.m_next" can incur a cache-line transfer since the memory address of m_tail may be not in the same cache-line as cmp.m_next the "state = next.m_state;" can incur another cache-line transfer But inside the pop() side of my FIFO queue there is only one cache-line transfer this is why it has scored 32% more on speed. the Bakery algorithm of the array based FIFO queue is faster than the above FIFO queue since i think it incurs less cache-lines transfers. Thank you, Amine Moulay Ramdane.
Back to comp.lang.pascal.misc | Previous | Next | Find similar
We have to be smart please aminer <aminer@toto.net> - 2014-04-13 19:09 -0700
csiph-web