[ffmpeg-devel] question about SDL_LockMutex in ffplay
QuickTime
ffmpeg
Sat Jul 9 10:59:18 CEST 2005
Oops!
There's a typo error in my previous mail
SDL_CondSigna(...) will call SDL_CondWaitTimeout(...)
SDL_CondWaitTimeout(...) will firstly unlock the mutex,and LOCK the
mutex again when it returns!
So,SDL_CondSigna(...) has no any bad effective on the other thread access!
On 7/9/05, QuickTime <ffmpeg at gmail.com> wrote:
> Dear :
> See my comments!
>
> >
> > Hi all,
> >
> > I am really confused with the SDL_LockMutex used in ffplay, I noticed that
> > when some one want to access a shared resource, it first locked it, but then
> > waiting
> > for another one to modify it, and if the other one want to modify it, it
> > must first lock
> > it too, but shouldn't a mutex can only be locked one time at the same time ?
>
> Of course ,the mutex can only be locked one time!
>
> > With some printf output, i found that every mutex can be locked twice, it
> > that the
> > correct behaviour ?
> > If a lock the mutex twice such as in function queue_picture, then when it
> > needs to
> > SDL_CondWait, there is no chance others to acquire the mutex, so others
> > can't SDL_CondSignal
> > it.
>
> I had the same question as yours about one year ago
> After I digged the implementation of SDL_CondSigna(...),I found the
> situation decribed would never occur!
>
> SDL_CondSigna(...) will call SDL_CondWaitTimeout(...)
> SDL_CondWaitTimeout(...) will firstly unlock the mutex,and unlock the
> mutex again when it returns!
> So,SDL_CondSigna(...) has no any bad effective on the other thread access!
>
> Take care
>
> //-----------------------
> //the implementation of SDL_CondWaitTimeout
>
> /* Wait on the condition variable for at most 'ms' milliseconds.
> The mutex must be locked before entering this function!
> The mutex is unlocked during the wait, and locked again after the wait.
>
> Typical use:
>
> Thread A:
> SDL_LockMutex(lock);
> while ( ! condition ) {
> SDL_CondWait(cond);
> }
> SDL_UnlockMutex(lock);
>
> Thread B:
> SDL_LockMutex(lock);
> ...
> condition = true;
> ...
> SDL_UnlockMutex(lock);
> */
> int SDL_CondWaitTimeout(SDL_cond *cond, SDL_mutex *mutex, Uint32 ms)
> {
> int retval;
>
> if ( ! cond ) {
> SDL_SetError("Passed a NULL condition variable");
> return -1;
> }
>
> /* Obtain the protection mutex, and increment the number of waiters.
> This allows the signal mechanism to only perform a signal if there
> are waiting threads.
> */
> SDL_LockMutex(cond->lock);
> ++cond->waiting;
> SDL_UnlockMutex(cond->lock);
>
> /* Unlock the mutex, as is required by condition variable semantics */
> SDL_UnlockMutex(mutex); //-----here,comments by ffmpeg at gmail dot com
>
> /* Wait for a signal */
> if ( ms == SDL_MUTEX_MAXWAIT ) {
> retval = SDL_SemWait(cond->wait_sem);
> } else {
> retval = SDL_SemWaitTimeout(cond->wait_sem, ms);
> }
>
> /* Let the signaler know we have completed the wait, otherwise
> the signaler can race ahead and get the condition semaphore
> if we are stopped between the mutex unlock and semaphore wait,
> giving a deadlock. See the following URL for details:
> http://www-classic.be.com/aboutbe/benewsletter/volume_III/Issue40.html
> */
> SDL_LockMutex(cond->lock);
> if ( cond->signals > 0 ) {
> /* If we timed out, we need to eat a condition signal */
> if ( retval > 0 ) {
> SDL_SemWait(cond->wait_sem);
> }
> /* We always notify the signal thread that we are done */
> SDL_SemPost(cond->wait_done);
>
> /* Signal handshake complete */
> --cond->signals;
> }
> --cond->waiting;
> SDL_UnlockMutex(cond->lock);
>
> /* Lock the mutex, as is required by condition variable semantics */
> SDL_LockMutex(mutex);//-----here,comments by ffmpeg at gmail dot com
>
> return retval;
> }
> //-----------------------
> >
> > Any help would be greatly appreciated.
> > Thx!
> >
>
--
//----------------------------------------
Heaven is not a place, it's just a feeling
More information about the ffmpeg-devel
mailing list