Hi Kishore On Tue, May 11, 2010 at 7:03 AM, sri ram vemulpali < [email protected]> wrote:
> Hi, > > First of all dead is caused because circular condition of waiting for a > resource or waiting on lock which is not released by holding thread. > Scheduling never causes dead locks. Also, in real time to schedule a high > priority task for an event it has some latency involved. So, there is no way > in the scenario you mentioned a dead lock occurs. Check your locks. > > Kishore > > I've double check it and it's appears to be ok. what really concerns me is that the system works perfectly when using notmal (SCHED_OTHER) policy, but only deadlocks when using SCHED_FIFO policy with the reader. That's why I suspect something wrong with fifo rt sched and pthreads lock or select() system call. what else could cause the mentioned behaviour ? Regards, > > On Thu, May 6, 2010 at 1:22 PM, Mohamad Tayssir Alkowatly < > [email protected]> wrote: > >> 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 >> > > -- Mohamad Tayssir Alkowatly
