January 18
On 1/17/21 6:54 PM, ludo wrote:
> Yes alright. I think the dev made a design mistake because he called synchronized( OpenAL.mutex ) when it should be more of a global, non OpenAL specific, mutex. I mean in the code there were things like  (pseudo-code)
> ---
> System {
>    private int[] buffer
>    func() {
>      synch (openal.mutex)
>      {
>        openal.dosmthg (buffer)
>        buffer.change() // buffer being the member of System
>        openal.dosmthg(buffer)
>      }
>    }
> }
> ---
> Basically, it's the entire buffers handling ( the 3 statements) which should be done the "atomic" way, not just the calls to openAL. So the mutex should be a member variable of System at worse. I just replaced
> synchronized ( openal.mutex )  {
> by
> synchronized { // create a global mutex
> Of course synchronized (open.mutex) would probably work, but getting the mutex of an abstract class which is used only in part of the calls looks like a design error to me!

Not sure if this is right. If the mutex should be protecting *more* then you should move the scope of the mutex out of the object into module space (and make it shared so it actually is used across threads).

Your code there allocates a mutex for that specific block, and nothing else. The mutex isn't more "global", it's more "local" (although, this will make it shared).

I'd follow some rules like:
1. If the mutex is for one specific block and does not need to be locked for any other code, then use a naked synchronized command. This is an odd case, because it is for a specific block of code, but works across all calls of that code. So the data it protects needs to be only used in that code, but also used across all instances of the objects. I'd use this one rarely.
2. If the mutex is for data in a specific object, make it a member of that object (or use the object itself as the mutex).
3. If the mutex is for static data in an object that is shared between threads, make it a shared static member of that object.
4. If the mutex is for static data in multiple objects, then put it in the module as a shared data item.

January 18
> The mutex isn't more "global", it's more "local" (although, this will make it shared).

Yes shared, this is what I meant by global :) Thanks, it's clearer now.

Next ›   Last »
1 2