jimfcarroll/xbmc — comment on commit fa29541976001a729f84b4713b34b14e36295582
File:  line 0
By jimfcarroll:

> Using CSharedLock insted of the SharedSection directly prevents the programmer from forgetting to unlock, right?

I didn't mean to imply that you should use the SharedSection directly. You are using it the right way.

I see what you mean with the CheckStatus now. I had missed that. You might consider having only one regular lock (see below).

If it's true that you will never be in the "read" sections of the shared lock in two threads simultaneously, then perhaps you shouldn't use shared locks, you should just use regular locks - they are easier to understand.

Alternatively, why not just use ONE regular lock? Do you gain an advantage in locking the DisplaySection separately from the DecoderSection? If different threads are never in each section simultaneously then there's no advantage, and it would be much simpler to use a single CriticalSection.

Those options would remove complexity. Or we could just move the entire codebase to an Actors model ;-)

Sure, a reentrant sharedlock would be nice, but if I had my way I'd remove the sharedlock all together :) . Currently it's only used in real time-sensitive code which is why I didn't want to take the hit of managing a vector of threads or an additional lock.

If you really want a reentrant shared lock, we should probably add one and leave the non-reentrant one so as to not effect the places it's already used.

It's up to you.