ReferenceCountedObject with multiple threads


#1

Is it possible to use the ReferenceCountedObject in a multi-thread environment?

ReferenceCountedObject::decReferenceCount() does:

   [i]if (Atomic::decrementAndReturn (refCounts) == 0) [/i]

and ReferenceCountedObject::incReferenceCount() does:

   [i]Atomic::increment (refCounts);[/i]

I’m wondering what happens if two threads get scheduled in the following way:

[THREAD A] [ReferenceCountedObject::decReferenceCount] Atomic::decrementAndReturn (refCounts) (returns "0")
[THREAD B] [ReferenceCountedObject::incReferenceCount]  Atomic::increment(refCounts)
[THREAD A] [ReferenceCountedObject::decReferenceCount] comparison with "0" -> delete this instance
[THREAD B] .... has a reference to a disposed object.... (?)

Am I missing something? Don’t we need a “full” mutex to avoid this situation?
Thanks


#2

I think that situation could only arise if there’s a raw pointer to the object somewhere, and both threads are hitting that pointer directly with increment/decrement calls. But you should never be using raw pointers to a ref counted object!

If you do things properly and always use ReferenceCountedObjectPtrs to refer to the object, then your example should be impossible, because I can’t imagine any way that two threads could both have pointers to an object whose ref count is only 1…


#3

Thanks, very clear.

The library is wonderful (I like it more than Qt/wxWidgets/FLTK!)
Wondering if there is a plan to support IPhone/IPad multi-touch gestures and Android.


#4

Don’t tell me, go and tell all the Qt users!

iOS multi-touch is already supported, though I’ve not attempted to do any interpretation of the touches as “gestures” yet.

Android’s an interesting problem because the apps have to be written in Java. I have a cunning plan involving LLVM and a customised bytecode generator that could allow c++ -> java compilation… no idea if such a crackpot scheme will work, but if it does, then yes, Android support will be possible!


#5

Well, you don’t always need Java/Dalvik in Android apps. You only need Java if you intend to interact with the Android platform (like the settings menu and so on).
You can write apps are plain C++ using the embedded libc ( http://developer.android.com/guide/basics/what-is-android.html and http://arstechnica.com/open-source/news/2009/06/android-goes-beyond-java-gains-native-cc-dev-kit.ars ) so the effort shouldn’t be too large, isn’t it ?


#6

I had a quick look at the NDK, but it seems quite limited, and a lot of useful functionality only seems possible via java. It’s also quite difficult to build NDK code that will run on all the different architectures.

I’m also quite intrigued by the possibility of compiling juce into java because the same system would allow an app to be turned into an applet, and that could have some interesting uses.


#7

It depends on what you want to do. With NDK, you get a cross compiler and the system is linux based, with a complete POSIX libc. So Juce could likely be compiled to a native binary/library.
You don’t really need the JNI stuff NDK provides, unless you want to integrate in the Android Market and in the official menus. Even in that case, we could write a kind of wrapper in Java calling Juce’s entry points, with “//TODO Create your application here”.

I agree that using LLVM to convert from C++'s AST back to Java sounds cool, while it usually the opposite that’s done (usually, you use LLVM to convert a Java bytecode to native binary for performance reasons).


#8

With all the buzz about the new google app store and native client, it would be strange if Android will not be targeted/supported as a full c++ platform.

And back to the original question: it that holds true, its fantastic - it makes ReferenceCountedObject more useful than boost::shared_ptr for many multithreading purposes.