|
From: Pim N. <pn...@ai...> - 2006-10-19 10:00:52
|
Julian Seward wrote: >>>priority thread is scheduled. Two threads will run interleaved (one with >>>possibly a lower priority). Is my concern grounded? >> >>Well set_sleeping will write to the pipe that all the other threads >>that are ready to run (ie not blocked in a system call made by the >>client) are trying to read from. >> >>How the kernel chooses which of threads which are trying to read from >>the pipe to wake up is up to it - but I assume it would respect the >>currently active scheduler algorithm? Yes you're right Tom. My fallacy was the folowing: I reasoned that as soon as the current running thread would write to the pipe another thread would be scheduled. But of course the scheduler may choose to continue running the current running thread, enabling it to reclaim Valgrinds lock. > I agree with Tom. Valgrind only really provides a lock which stops > more than one thread running at once. It doesn't mess with scheduling > or priorities in any other way. So unless the kernel is doing something > strange, your priorities should be observed. Can you create a small > test case that shows the problem? I tried, but it showed me I was wrong. Well I can happily use Valgrind without having to worry about this! Thanks to both of you for your quick replies. Pim Nijdam -- This message has been scanned for viruses and is believed to be clean |