[openbeos] Re: Media Kit Query
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 20 Sep 2002 21:42:24 CEST (+0200)
John Hedditch <jhedditc@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> I have a question to do with locking in this kit.
>
> The idea of the Lock(), Unlock() calls seems to be to prevent the
> list of
> supported formats/descriptions changing whilst you're looking at it,
> i.e to
> prevent some sort of race condition between RewindFormats/
> GetNextFormat and
> the MakeFormatFor routine, plus the obvious one where
> ...
> My question is, if MakeFormatFor is called with BMediaFormats locked,
> should
> it sleep and wait for the lock to be released, or should it return an
> error?
The Lock()/Unlock() pair is only for external parties to lock the
internal media formats list, so that no other application can modify
it.
Of course, you have to lock this list internally in every function, or
else you wouldn't be thread-safe.
Normally, MakeFormatFor() would just wait until the lock is released
(anything other wouldn't make much sense), but I don't know how this
class handles it - you could write a short test app to verify it.
> Furthermore, although the BeBook says that Lock()/Unlock() is only
> necessary
> with the GetNextFormat/RewindFormats calls, the MakeFormatFor routine
> would seem to need to acquire it as well, for the same reason.
While MakeFormatFor() is an atomic operation from the app's POV,
GetNextFormat() is not; while you are traversing the list, other teams
could change the list, and make
it inconsistent.
That's why MakeFormatFor() would hold the BMediaFormats::s_lock while
it does its job, and that's why you want to have this possibility for
your own app, too.
Any clearer now?
Just look what member variables you have in BMediaFormats, and that's a
good hint at how it should work (well, sometimes ;-)).
Adios...
Axel.
Other related posts:
