QMultiHash - crashing

[wysota]

If multiple threads are involved, they are likely to crash your application in a way you describe. Or you keep pointers to unexisting objects in the hash. You might want to use QPointer instead of simple pointers. At least you'll know if objects are still valid.

[steg90]

Hi,

Got this working now, no crashing, it was because I was passing a pointer to a structure which was created in my thread to another class outside of this thread.

I'm taking it that it is unwise to pass pointers to objects from one thread to another?

Regards,
Steve

[freeskydiver]

Hi,


I'm taking it that it is unwise to pass pointers to objects from one thread to another?

You must know what you to doing. It's sometimes no other way for exchange of data.

[wysota]

If those objects are QObjects then it's never safe unless you change the thread affinity at the same time, so that the object is moved to the other thread. But you can't access a QObject from two threads simoultaneously - you have to decide which is going to own the object. And then you can communicate with the object only with events (and signals/slots which use events).

[steg90]

Thanks for that, something to remember in the future.

[freeskydiver]

I see a small difference. You can use the same object from different threads. You must have a threadsafe call of the functions. This can you do with QMutex for example. Signals/Slots are very nice, but this is a Qt special. In C++ without Qt, you must communicate over threads, too.

[steg90]

Hi,

I did try using QMutex around the object in question, but to no avail, it still crashed...

The mutex will just stop the object from being modified by another thread while one thread is updating it. ( AKA Consumer / Producer problem ).

Regards,
Steve

[wysota]

I see a small difference. You can use the same object from different threads. You must have a threadsafe call of the functions. This can you do with QMutex for example. Signals/Slots are very nice, but this is a Qt special. In C++ without Qt, you must communicate over threads, too.

You can't guard an already existing class with mutexes. It's just not possible. You'd have to wrap all calls in all existing classes that call the object in critical sections. The problem is not that your function is not reentrant (because you are working around this particular problem when putting mutexes into your class) but that the object you call is not thread-safe and using mutexes in your code won't help unless you protect every other code that calls the same object. If you miss at least one, you're just calling for trouble (that's one of the problems with protecting code instead of data, by the way).

So it doesn't matter whether we're talking about Qt or non-Qt applications. If you don't protect everything, you're not protected at all.

[freeskydiver]

You can't guard an already existing class with mutexes. It's just not possible. You'd have to wrap all calls in all existing classes that call the object in critical sections.

Correct thats the only way, but what should I do? When I must use classes who are not thread safe. Ok it's a dangerous way, but possible.

[wysota]

It's not possible, if you can't overload every method that calls the object! And this is exactly the case.

[freeskydiver]

It's not possible, if you can't overload every method that calls the object! And this is exactly the case.

That's not essential. When I use a class, then I must encapsulate the calls of the not threadsafe class.

[wysota]

Yes, but all calls, not only the ones you make. If you use some kind of architecture (like Qt) it is possible that the architecture calls the objects (like QObjects), which is the exact case here. Thus you can't make QObjects thread-safe just by protecting your code.

[freeskydiver]

Upps.... you are right.
When the system call my object then can it crash.