Hi Julian Maybe I can help with the Sleep(0) call.
If a thread calls the sleep function, the thread will be suspended and waits at least the time that you specify until he will be resumed from the scheduler. The scheduler takes a look and makes the next thread the current running thread (there will be only one running thread per cpu in the system). If there is no other thread, the scheduler sets your thread again in the "ready" state and then to the "running" state. That is whats happen if you have more then 0ms to sleep. If you call Sleep(0), the scheduler is just looking around, if there is another thread that wants to run. If no, the current thread will still be the running thread until he's preempted, or calls again the sleep function. So sleep(0) is just a cooperative way to say: "Hey, I don't need the CPU to wait. If someone else wants it - take it". If you call Sleep(1) your thread will be suspended and remains to this state until a new schedule will be happen. So if you have high CPU utilization with Sleep(0) that means a busy wait. If you call Sleep(1) your thread will be preempted and will be suspended for at least this one millisecond. Hope this helps Lothar On 23 Jun., 01:27, Julián Hidalgo <[EMAIL PROTECTED]> wrote: > Hi> Sure I will do that. I think it would be a good idea to store the wait > > salue in the .config file instead of hardcoded the value. What do you > > think? > > Is there an object were all .config values are stored? > > It looks like nobody has applied the patch (it's > inhttp://www.mertner.com/jira/browse/MBUNIT-134by the way). > I reviewed it and it seems to work, but I'm not sure why really. Maybe > somebody with more knowledge of threading > can tell me why. There are 3 calls to Thread.Sleep(0) in the > ThreadCollectionRunner. I tried 3 things: > > - Changing the 0 to 10 one at a time (to see if it was a single call the > responsible of the high CPU utilization): still high > CPU utilization, but at different stages. > - Removing all the calls: no effect, still high CPU utilization > - Using different values (1, 10, 100): almost zero CPU utilization. > > So it looks like the Thread.Sleep(0) calls need to be there, with any > value greater than zero, but why? I'm afraid > of applying the patch without knowing if it's going to screw something. > Also how do we test this? We don't have > CPU load monitors. Another thing I find strange is this loop: > > public void WaitForFinishing() > { > bool alive = true; > while (alive && this.Threads.Count>0) > { > alive=false; > foreach(Thread thread in this.Threads) > { > if (thread.IsAlive) > { > this.Threads.Remove(thread); > alive=true; > break; > } > } > //Thread.Sleep(0); > } > } > > If the method is called WaitForFinishing() why is it removing threads > that are alive? Makes no sense for me. > The same thing it's being done in a method called > WaitForFinishingSafe(), but within a try/catch block. > > > Is there an object were all .config values are stored? > > I'd rather add a new property to the ThreadedRepeatAttribute attribute > than using a configuration file, unless Andy > decides we should use one. > > Julian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MbUnit.User" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/MbUnitUser?hl=en -~----------~----~----~----~------~----~------~--~---
