<p><br>
On Mar 2, 2012 10:37 AM, "Lennert Buytenhek" <<a href="mailto:buytenh@wantstofly.org">buytenh@wantstofly.org</a>> wrote:<br>
><br>
> One problem you can get into with this scheme is a kind of priority<br>
> inversion.  If the low priority process does:<br>
><br>
>        fd = open("/foo/bar", O_RDWR);<br>
>        flock(fd, LOCK_EX);<br>
><br>
> and the high priority process then also does:<br>
><br>
>        fd = open("/foo/bar", O_RDWR);<br>
>        flock(fd, LOCK_EX);<br>
><br>
> and the low priority process then does:<br>
><br>
>        sleep(1);<br>
>        flock(fd, LOCK_UN);<br>
><br>
> and the system then goes into suspend, you'll not wake up again<br>
> after that second expires, and you might not wake up again soon<br>
> at all.  The low priority process doesn't even have to sleep<br>
> explicitly, if it takes a page fault you get basically the same<br>
> thing.</p>
<p>I believe the cgroup method will catch this though.  I would have to double check, but I think that the cgroup becomes partially frozen returning EBUSY until all the processes can properly be frozen.  At that time I believe it is up to userspace to thaw, or refreeze the group, unless the blocking process ends in which case the entire cgroup is set to the frozen state.</p>

<p>-Jon</p>