[erlang-questions] : Subtle behaviour of Erlang scheduler

[Rickard Green]

Yes, this is the way to do it.

We had a discussion about these things this morning at OTP, and we have 
decided to leave things as they are (no propagation of prios, and leave 
code server on prio normal).

We reason like this: Priority levels other than normal, should normally 
not be used. When other priority levels are used, they have to be used 
with extreme care. The programmer have to take things like this into 
account.

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

Raimo Niskanen wrote:
> I guess the solution for the problem at hand would be to make
> sure all code for the high priority processes are loaded
> before they are started, e.g by calling Module:module_info/0
> on them. That trick is done by the code server itself
> to ensure it can start without a running code server.
> 
> 
> 
> On Fri, May 25, 2007 at 11:48:43PM +0200, Rickard Green wrote:
>> 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
>