[vlc-devel] vlc_object_signal removal

[Rémi Denis-Courmont]

Le lundi 8 septembre 2008 15:28:07 Olivier Aubert, vous avez écrit :
> Thanks for the explanations.  The fact is that wrt. your reasoning ("It
> makes no sense to signal an object without _then_ changing some of its
> data/state"), the locking mechanism is here used only for signalling,
> not protecting the access to the object data.

It makes no sense to wait for "nothing" to happen. If you are solely waiting 
for time to elapse, use mwait() or msleep(). If you are not waiting for 
anything, then use pause() or poll(NULL, 0, -1), or better yet, terminate the 
thread if you can. Consequently, it makes no sense to signal a condition 
variable if you don't change some of the associated state, since no thread 
would be waiting for nothing to happen.

> In other words, the code in vout_intf.c knows that its caller has the lock
> for an object, and that it will wait for a signal before reading it.
                          ^^^^^^^^^^^^
Okay, first paragraph from the previous email (emphasis added):

"When using condition variables there is always a boolean predicate
involving shared variables associated with each condition wait that is true
if the thread should proceed. SPURIOUS WAKEUPS FROM THE vlc_cond_wait() OR
vlc_cond_timedwait() FUNCTIONS MAY OCCUR. Since the return from
vlc_cond_wait() or vlc_cond_timedwait() does not imply anything about the
value of this predicate, the predicate should be re-evaluated upon such
return."

> Thus the vout_intf code considers that it has the right to modify the
> object, as per a kind of lock delegation.

Not only does this not work, it seems to not account for concurrent snapshot 
requests. In both cases, we end up with potential invalid memory usage.

> > In other words, the current snapshot support may currently:
> > - wake up when it should not (detecting a bogus failure),
>
> This does not really bother me.

Well, then I suggest you remove the vlc_object_wait and make the function fail 
all the time. At least, it would have a predictible outcome.

> > - miss the signal, and effectively deadlock.
>
> This is more serious, but there is no real way of avoiding this, short
> of a timeout mechanism, is there?

Second paragraph (emphasis added):

"The vlc_cond_signal() or vlc_cond_broadcast() functions may be called by a
thread whether or not it currently owns the mutex that threads calling
vlc_cond_wait() or vlc_cond_timedwait() have associated with the condition
variable during their waits; however, IF PREDICTABLE SCHEDULING BEHAVIOUR
IS REQUIRED, THEN THAT MUTEX IS LOCKED BY THE THREAD CALLING
vlc_cond_signal() OR vlc_cond_broadcast()."

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary