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


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

Please read again

Started byaminer <aminer@toto.net>
First post2014-04-19 20:40 -0700
Last post2014-04-19 20:40 -0700
Articles 1 — 1 participant

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


Contents

  Please read again aminer <aminer@toto.net> - 2014-04-19 20:40 -0700

#2194 — Please read again

Fromaminer <aminer@toto.net>
Date2014-04-19 20:40 -0700
SubjectPlease read again
Message-ID<liv52o$56r$1@news.albasani.net>
Hello,


I have discovered a serious problem today, when you are using a 
Ticketspinlock or an array based lock, don't use the "pause" asm 
instruction only whenyou are spinning waiting for the lock or don't use 
a proportional backoff using the "pause" asm instruction only when you 
are spinning waiting for the lock, cause this can lead to a big problem 
that look like a lock convoy, if you start more threads than cores for 
example the system will switch between the threads and giving each 
thread its quantum time even if the threads don't enter the Enter() 
method of the lock, and this will lead to a big problem , this can slow 
by much the threads entering the lock, this will look like a lock convoy 
and this is not acceptable, so the solution is to use a sleep(0) when 
you are spinning waiting for the lock inside the Enter() method of the 
lock,  but i have noticed that sleep(0) for example lowers a lot the 
throughput of my concurrent FIFO queue by 3x times, and 
swithchtothread() will also lowers a lot the throughput of my concurrent 
FIFO queue by 3x times ... so this is very sad ! so from now on 
becarefull of this serious  problem, i have just tested it on my 
computer and it has showed up and it's a serious problem  !


Thank you,
Amine Moulay Ramdane.

[toc] | [standalone]


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


csiph-web