Author: Paul Clarke
Date: 04:21:06 11/30/04
Go up one level in this thread
[There are bits of two different articles in the following - PaulC.] On November 30, 2004 at 04:27:18, Daniel Shawul wrote: >On November 30, 2004 at 03:44:13, Russell Reagan wrote: > >>On November 30, 2004 at 02:22:49, Daniel Shawul wrote: >> >>csrss = Client/Server Runtime SubSytem >> ^ ^ ^ ^ ^ >> >>One of its duties is creating threads. >>> So it doesn't matter how much cpu it uses? >>>Because it sometimes uses upto 20% cpu. I am not creating and destryoing lots of >>>search threads, 400 splits in a 10 second search maximum. >> It matters to the extent that the time CSRSS uses isn't being spent in your search. Are you actually creating a thread each time you split (and destroying the thread when it finishes)? If so then even 40 splits/second could incur quite a lot of overhead - creating a thread isn't a cheap operation. >>My guess is that your code is making system calls to do synchronization (maybe >>EnterCriticalSection, OpenMutex, and so on) instead of using a spin lock. Do those calls actually involved CSRSS? I'd have thought they'd simply call into their kernel equivalents. > > I do use spinlocks :) > I replaced the critical section code with spinlocks some time ago >but it brought nothing at all. When i flipped from mutexes to critical sections >that really brought something. But here on my single cpu critical sections are >as fast if not faster than spinlocks. May be the story is different in multiple >cpus,that's why i still kept the spinlocks. This is exactly what I'd expect. You get a big benefit by moving from mutexes to critical sections because acquiring a mutex always involves a transition into kernel mode and back, which isn't cheap; acquiring a critical section avoids this unless you actually need to wait for another thread to release it. A spinlock always avoids the kernel mode transition: if a thread can't immediately acquire the spinlock it spins in a tight loop within your thread until the spinlock is available. This explains why critical sections are better than spinlocks on single CPU machines: if a thread can't acquire a critical section then it goes into a wait state and other threads (including the one holding the critsec) get a chance to run, but if a thread can't acquire a spinlock then it hogs the CPU until the end of its current time slice, preventing your program doing any useful work until then. >May be you can check it at your dual and see cssrs.exe is using reasonable cpu >time. > > >>However, guessing is a sure fire way to waste a lot of time. >> >>Profile your code. It will tell you exactly where your program is spending its >>time and which system calls (if any) are being called. Then you will know, and >>we won't have to guess :) > i found it hard to debug parallel search programs because i can't reproduce >errors. If it breaks at wac 107 now,it will not break at that position when i >try to fix the problem. So i have to use my brain to debug the code than the >debugger. Welcome to the wonderful world of multi-threaded programming :-). In this case, though, it sounds like the problem is happening consistently, and profiling is likely to help.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.