Re: pthread with SCHED_FIFO calling select() causing system deadlock

[Mohamad Tayssir Alkowatly <idoit.ief@xxxxxxxxx>]

Hi Kishore

On Tue, May 11, 2010 at 7:03 AM, sri ram vemulpali <kishore.kernelmm.dev@xxxxxxxxx> 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 <idoit.ief@xxxxxxxxx> wrote:

Hi

On Thu, May 6, 2010 at 7:29 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:

Hi...

On Wed, May 5, 2010 at 17:39, Mohamad Tayssir Alkowatly
<idoit.ief@xxxxxxxxx> 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