lkml.org 
[lkml]   [1999]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Threads in linux, contd
On 09/02/1999 19:36 -0400, Vladimir Dergachev wrote:
>>
>> Not hard pushed at all. The problem is that both cpus have caches. So
>> suppose you have two static variables:
>>
>> static char A;
>> static char B;
>>
>> variable A is accessed often by thread 1, variable B is accessed often by
>> thread 2. (if you want something more tangible, imagine that each thread
>> is computing a checksum of it's own array and these variables keep the
>> result - this is just for the sake of the argument).
>>
>> Now on UP system each thread will take approximately half the cycles
>> available. On SMP system threads will do same if scheduled to one cpu, but
>> will do considerably worse when scheduled to two different cpus.
>>
>> As pointed by Mark Hans to me ia32 has 32byte cache lines. Thus if the
>> above example gets compiled so that variables A and B are further than 32
>> bytes apart all is ok and no perfomance loss is expected. However if they
>> are close (as they should be) each time the threads run on two different
>> cpus making you are limited to FSB speed.
>>
>> Note that the same behaviour will happen even when variables are declared
>> long. I would also imagine that on a system with only one cpu-intensive
>> multi-threaded program running you'll get a slowdown as opposed to the
>> case when you start any other program that will take that cpu from you.
>> (say a while(1) loop).
>>


Of course, the argument can be made (and has been many a time in many
different forums) that using global variables (especially unprotected
by mutexes or other such mechanisms) is a **bad thing** in MT programming.
In many many ways, global variables are a big bad accident waiting to happen.
Better to make A (from your example) local to the thread that uses it,
and the same with B. If the variable needs to be shared between threads,
then make it global, but serialize access to it. If it doesn't need to
be visible to both threads, don't make it visible to both threads.

IMHO, that's just good programming practice. Granted, your example is
valid as far as the expected effects are stated, but that doesn't mean
it's good code.


tw




--
+------------------------------+--------------------------+
| Tim Walberg | Phone: 847-782-2472 |
| TERAbridge Technologies Corp | FAX: 847-623-1717 |
| 1375 Tri-State Parkway | twalberg@terabridge.com |
| Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 |
+------------------------------+--------------------------+
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.169 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site