[erlang-questions] Subtle behaviour of Erlang scheduler

Ulf Wiger (TN/EAB) <>
Sat May 26 00:22:07 CEST 2007


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:  
> [mailto:] On Behalf Of 
> Rickard Green
> Sent: den 25 maj 2007 23:49
> To: KatolaZ
> Cc: 
> 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
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
> 




More information about the erlang-questions mailing list