Messages in this thread | | | Date | Fri, 3 Sep 1999 12:06:32 -0400 (EDT) | From | Vladimir Dergachev <> | Subject | Re: Threads in linux, contd |
| |
On Fri, 3 Sep 1999, Tim Walberg wrote:
> 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.
The thing is that there is _no_ contention in the example. I.e. I'll say that access to these variables is serialized - it will not change the example. The problem is that there is an implicit dependency between variables because of the way they were placed in the file.
Vladimir Dergachev
PS I do agree that making A local would be better in the example. However this is just an example..
PSS Does anyone know of any kind of computationally intensive multithreaded software package/benchmark to test out whether this is noticable or not ?
> > 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 | > +------------------------------+--------------------------+ >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |