Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #2152 > unrolled thread

We have to be smart please...

Back to article view | Back to comp.programming.threads

Contents

  We have to be smart please... aminer <aminer@toto.net> - 2014-04-13 19:08 -0700

#2152 — We have to be smart please...

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.

[toc] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web