[erlang-questions] Subtle behaviour of Erlang scheduler

[Rickard Green]

The 'max' priority is an undocumented feature for OTP internal use only.
Don't tell anyone about it :)

Scheduler threads will pick processes from the run queue(s) in the same
way as on the non-SMP system. When there exist high prio processes, only
high prio processes will be picked. Since there might be fewer runnable
high prio processes than scheduler threads, normal and low prio
processes may run at the same time as high prio processes.

The documentation of priorities could be improved. I've put this on the
todo list.

BR,
Rickard Green, Erlang/OTP, Ericsson AB.

Ulf Wiger (TN/EAB) wrote:
> Ooh, didn't think of that. (:
> 
> BTW, where is it documented that 'high' and 'max'
> are strict priorities, and does this still hold
> true in an SMP environment (i.e. can one high
> priority process starve all normal priority 
> processes)? 
> 
> The code server is a pretty heavy process to 
> run on a blocking priority. One way to address
> the problem would be to make all priorities 
> non-strict, right?
> 
> BR,
> Ulf W
> 
> 
>> -----Original Message-----
>> From: erlang-questions-bounces@REDACTED 
>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of 
>> Rickard Green
>> Sent: den 25 maj 2007 23:49
>> To: KatolaZ
>> Cc: erlang-questions@REDACTED
>> Subject: Re: [erlang-questions] Subtle behaviour of Erlang scheduler
>>
>> This behavior is due to the fact that the code server runs on 
>> priority normal.
>>
>> If the code for the timer module hasn't been loaded before 
>> you start your program, proc1 will block forever in the call 
>> to timer:sleep waiting for the code server to load the code 
>> for the timer module. Since the code server runs on normal 
>> prio, it wont be scheduled until the high prio run-queue is empty.
>>
>> Try l(timer) before running you program, and everything will 
>> work as expected.
>>
>> This behavior is in my opinion unfortunate, and we will 
>> probably increase the priority level of the code server some 
>> time in the future.
>>
>> BR,
>> Rickard Green, Erlang/OTP, Ericsson AB.
>>
>>
>> KatolaZ wrote:
>>> Dear Erlang Gurus,
>>>
>>> we have tested the priority system of the processes and we are 
>>> experiencing a very strange behaviour.
>>>
>>> Take a look at the simple code attached: if you run 
>> "test:test()" from 
>>> the shell, the system hangs and "proc2" never ends blocking also 
>>> "proc1" and the shell. We think that this is due to the fact that 
>>> "proc2" hasn't any synchronization point, i.e. send or receive 
>>> messages, etc. In any case, this is quite strange since also "proc1"
>>> has priority set to "high", so sooner or later, it should 
>> be selected 
>>> to be scheduled.
>>>
>>> Now kill the shell (with CTRL+C, you don't have any other option!), 
>>> uncomment the "timer:sleep(1)" statement in proc2, recompile and 
>>> everything seems to work fine: "proc2" and "proc3" exit, 
>> and the value 
>>> reached by the counter proves that proc2 really runs with a higher 
>>> priority than proc3.
>>>
>>> Well, now, don't exit from the shell, comment again the 
>>> "timer:sleep(1)" line, compile the code with "c(test)", and run it 
>>> again. Well, now it works!!! But if you (once again) exit 
>> the shell, 
>>> run "erl" again and launch "test:test()" once more.... it blocks!!!
>>>
>>> What's behind this strange behaviour? An undocumented 
>> feature? A bug 
>>> in scheduler initialization? Too many beers before sitting down for 
>>> coding :-))) ???
>>>
>>> All the best,
>>> --Enzo and Corrado
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>