Stefan Lucke schrieb: > On Montag 25 September 2006 19:37, Martin Wache wrote:
>> On non-linux systems, yes. As soon as you are using strict posix mutexes >> trying to lock a mutex from the thread which already holds the mutex >> always results in a deadlock. >> >> But there may be other problems as well: if you lock a mutex, and then >> call a method which locks the same mutex again, this second lock will >> fail with -EAGAIN (in case of a mutex PTHREAD_MUTEX_ERRORCHECK_NP), but >> not block. If this method now unlocks the mutex, the mutex will be >> unlocked, even though the calling method still thinks it holds the mutex. >> I did not try this out, maybe I'm wrong here (it depends on the >> implementation of the library... there are also recursive locks which >> are allowed to double lock) >> So I would like to avoid double locking... >> >> Thinking again about all this, I don't think that one actually needs to >> call DrawStill() from other than cVideo, it is only used to redraw a >> frame when the OSD changes and no video currently is displayed. >> I think the name is misleading, even still pictures should be displayed >> with DrawVideo(), since on OSD change one still wants to have the last >> still picture, and only DrawVideo() updates oldPicture. So I would >> suggest to remove the lock from DrawStill(), make it private and put a >> comment on it, that it only should be called with oldPictureMutex held. > > DrawStill() is called from outside of video.c -> ShmClient.c. > So we should have a non-locking private one, and a locking public. > Yes, I forgot that ShmClient uses DrawStill(), but I don't see a reason why ShmClient should not use DrawVideo(). So we could also change DrawVideo() to be allowed to be called without syncTimer and make DrawStill() private. But as long as no mutexes are taken twice I don't mind :-) Bye, Martin _______________________________________________ Softdevice-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/softdevice-devel
