Re: BMidiEndPoint

Michael Pfeiffer <[email protected]> Fri, 11 Oct 2002 08:59:55 -0700
Newsgroups gmane.os.openbeos.midi
Message-ID <GBEC4Z98CBK51VTA671FCVSA9MLYWIG.3da6f57b@name-sgc3h6xcx5>
>I still think it is not thread save. can you please prove why do you think it should be save=3F
>The comment says:
>
>// thread-safe as long as thread that calls acquire has already a reference to the object

>If you have only one single thread that is calling aquire or release, you don't need atomic=5Fadd() at all.
>
>Assuming one thread calls Acquire(), and passes the pointer to another thread, which calles release.
>
>If you have two or more threads, the following can happen:
>
>fRefCount is 1
>
>Thread 1 calls Acquire, fRefCount is now 2
>Thread 2 calls Release, and gets interrupted after atomic=5Fadd, but before if(), fRefCount is now 1
>Thread 1 calls Release, (does not get interrupted) fRefCount is now 0, and executes "delete this";
>Thread 2 continues, checks fRefCount, it is still 0, and executes "delete this";
>
>You see, it is NOT multi thread save. You delete this twice.
>
>You should really use the return value of atomic=5Fadd() to avoid that.

You are right, how could I overlook this. Promise to examine my own code the next time
before replying :)

I assume that Thread 2 is started after Thread 1 has called Acquire.

Otherwise there would be this problem:
Assume the same situation as above: fRefCount is 1
Thread 1 calls Acquire, and gets interrupted at the begin of the method body, fRefCount is not changed yet
Thread 2 calls Release, decrements fRefCount to 0 and deletes the object
Thread 1 continues accessing data of a not existing object! Thread 1 has no chance to detect that
the object is deleted.

- Michael