[erlang-questions] : Subtle behaviour of Erlang scheduler
Mon May 28 10:00:36 CEST 2007
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
> 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
> This behavior is in my opinion unfortunate, and we will probably
> increase the priority level of the code server some time in the future.
> 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
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions