Hi On Thu, May 6, 2010 at 7:29 PM, Mulyadi Santosa <[email protected]>wrote:
> Hi... > > On Wed, May 5, 2010 at 17:39, Mohamad Tayssir Alkowatly > <[email protected]> wrote: > > Hi all > > > > As the long subject indicates, but I'll elaborate the situation: > > > > I have three pthreads reader/worker/writer. the reader and the writer are > of > > the same priority and SCHED_FIFO policy while the worker has a lower > > priority and a SCHED_RR policy. > > The reader is continuously calling select on multiple fds to read from, > when > > data available it reads and puts them in a reader/worker queue. worker > works > > then puts the result in a worker/writer queue. writer writes the result > to > > some fds. > > > > this program causes a system wide deadlock the moment it started when > > running on a uni-processor system. > > I think this explanation would answer your doubt (from > SCHED_SETSCHEDULER(2)) > > A SCHED_FIFO process runs until either it is blocked by an I/O > request, it is preempted by a higher priority process, or it > calls sched_yield(2). > > So, in other word, somehow you make one of these SCHED_FIFO process > runs but not blocked sometimes or voluntarily yields its runtime. > > I expect select() to be considered as an IO request, hence the process would be blocked until some IO event become available. If that was not right then the model I suggested for the program is incorrect as calling sched_yield won't help the situation (the scheduler will choose the same process to run again because it remains runnable). Can anyone confirm if my assumption is valid -although apparently not ;) and how such case could be solved ? Cheers, > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -- Mohamad Tayssir Alkowatly
