[erlang-questions] : Subtle behaviour of Erlang scheduler

Rickard Green rickard.s.green@REDACTED
Thu May 31 12:20:22 CEST 2007

Erik Stenman wrote:
> Rickard Green wrote:
>> KatolaZ wrote:
>>>>> So, just for the purpose of discussion, why don't think at "virtual"
>>>>> synchronisation points for high priority procs ? I.e., if a high
>>>>> priority task has not been interrupted for X reductions (beeing X a
>>>>> relatively large integer), then goto do_schedule1 anyway, letting
>>>>> other high priority process to run....
>>>> If I understood you right, you want the scheduling to work as it is
>>>> implemented right now.
>>>> Regardless of priority, a process is unconditionally scheduled out when
>>>> it has consumed (currently) 2000 reductions (since it was last scheduled
>>>> in). I.e., a busy loop in a high priority process will not prevent other
>>>> high priority processes from running, but it will prevent normal and low
>>>> priority processes from running.
>>> Unfortunately, it seems to be false, or I'm missing something!  Here
>>> is a simple example where all code for high prio processes is loaded
>>> (it is indeed a self-contained module!), and proc_high2 is starved by
>>> proc_high:
>> No, it is not false. The problem is that proc_high2 never gets the 
>> chance the set prio high. It is still on prio normal. You have to spawn 
>> it with prio high (see spawn_opt) in order for this example to work as 
>> expected (and it will; i've tried it).
> I guess spawning with prio high also is a bit dangerous unless the 
> process you
> are spawing from (p1) also has prio high, otherwise the first spawned 
> high prio
> process (p2) might starve the spawner. (If p1 is suspended before it 
> spawns p3.)
> Am I right?

Yes, if you removed prio high from p1 in this example you could 
potentially get that problem.

Rickard Green, Erlang/OTP, Ericsson AB.

> /Happi
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list