On Thu, Jan 27, 2011 at 11:31 AM, Blaise Gassend
<
blaise@willowgarage.com> wrote:
>> 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.
>
> I wasn't thinking of hacking fairness into the mix, but rather using
> some extra signaling between the threads. One thing I have done in
> wpa_supplicant_node (wpa_supplicant_node.cpp), in which I had a
> similar situation is the following:
>
> - There is a state variable that indicates what state the system is
> in. For you that would be Streaming, ReconfigurePending,
> StreamingThreadPaused.
That is basically what I had in mind.
> In your case, since there are clear bounds on what the time between
> frames can be, sleeping for 1ms is probably just fine.
I had less time to work on it today than I'd hoped. I did verify that
the 1ms sleep eliminates the livelock, which pretty well proves that
the problem is "unfairness" in the lock implementation.
Thanks for the detailed example. I will probably do something similar
but simpler. I want to avoid big changes with the initial Diamondback
release coming up right away.
--
joq
(text/plain)