On Thu, Jan 27, 2011 at 1:53 AM, Brian Gerkey <
gerkey@willowgarage.com> wrote:
> On Wed, Jan 26, 2011 at 10:53 PM, Blaise Gassend
> <blaise@willowgarage.com> wrote:
>> I could believe that the polling thread is reaquiring the lock before
>> the reconfigure thread does. I don't think that there is any guarantee
>> that a thread that is waiting on a lock will get the lock before the
>> thread that released the lock reaquires it.
>
> I was about to respond with something like, "that's crazy, of course
> the waiting thread will get the lock." Then I asked Google. This
> discussion is on point:
> http://www.mail-archive.com/linux-il@cs.huji.ac.il/msg48835.html
> Seems that the POSIX spec says that fairness in mutex acquisition is
> optional, and that the Linux implementation doesn't guarantee it,
> especially in tight lock/unlock loops. That was certainly news to
> me, and I'm sure that I've written code in the past that assumed mutex
> fairness.
>
>> Have you tried putting in a short (1ms) usleep in the poll loop? That
>> would be a quick way to test this theory (though probably not the
>> cleanest long term solution.
>
> There are a few suggestions in the discussion linked above, including
> setting the thread scheduling policy, and explicitly yielding from
> within the mutex hoarding thread, similar to Blaise's suggestion.
Thanks for the pointers, guys. My problem looks exactly like the
starvation issue you discovered.
I'll do some experiments later today and report back what I learn.
For the special case of two threads belonging to the same class, it
should be relatively simple to hack some "fairness" into the mix. A
more general solution would be hard, I think.
Regards,
--
joq
(text/plain)