2015-11-20 13:44 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

> On 20 Nov 2015, at 13:03, Thierry Goubier <thierry.goubier@gmail.com> wrote:
>
>
>
> 2015-11-20 12:46 GMT+01:00 Martin Dias <tinchodias@gmail.com>:
> Hi!
>
> With Guille and Pablo this morning we found what is the problem and apparently fixed it. The problem is that there is a process in priority 10 that takes the delay lock (accessProtect semaphore) and go to sleep. Then the #benchFor: launches another process in priority 79 that tries to take the delay lock but, since it's taken by the other process, it goes to sleep. But the UI process is in priority 40 so it will always have priority over the one that has the lock. Consequence: the process in priority 10 has the delay lock and will never be awaken until the UI process gets suspended.
>
> I believe this is a text book example of priority inversion.
>
> Kudo's for finding it!

Great work, great team !

Also a bit scary.

No. And yes.

No, because its inherent to the Pharo scheduler.

Yes, because anywhere you acquire a non-local lock in Pharo in a process with less that max priority, it may happen. And that the cooperative nature of the Pharo scheduler increase the risks.

Thierry