Hi
--
Mohamad Tayssir Alkowatly
On Thu, May 6, 2010 at 7:29 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi...
I think this explanation would answer your doubt (from SCHED_SETSCHEDULER(2))
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.
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,
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
