Re: Re: A possible race condition in Packet::invalidateHeader()

Dear Peter

My response in bold

Peter Dimov wrote:

Hi Atul,

Did you verify that a race occurs?

Not with some tool like DRDT on solaris 10 ( Btw, it is a great tool and could be the sole reason to port any multi threaded program to solaris ;-) 

See http://developers.sun.com/sunstudio/downloads/drdt/drdt_index.html 

I am planning to do it once we start giving out MT releases ;-)

I that should not be the case.
…. Yes ;-)
Let me know if I’m wrong!

I think I am wrong… However I am not too sure if we should not stick a volatile keyword before

volatile Data *d;

in Packet…

See http://www.ddj.com/dept/cpp/184403766 for example

 Let me know if I am wrong ( Anything multi-threaded should be handled like a burning hot iron rod, IMHO ;-)

It’ll be great if you can take a look at Packet from the multi-threading perspective.

Sure ;-) 

Regards,

Peter

atul wrote:Dear all

While doing the refactoring of this function, the race poped out …. ;-)

if (!x->ref.deref())

delete x;

Now what happens thread T1 has finish checking the above conditional and is then pre empted … T2 runs the the same conditional and deletes x. Thread T1 resumes and deletes x

As we are using thread safe functions to swap ( if I am right ) the pointers, we should consider all races

Adding multi-threading at some later point in the code is very hard …

—- cheers atul

Would you like to post a relpy?


This post is a reply to:
Re: A possible race condition in Packet::invalidateHeader()
Hi Atul, Did you verify that a race occurs? I that should not be the case. QBasicAtomic::ref() and QBasicAtomic::deref() are atomic operations. if (!x->ref.deref()) delete x; The implementation of deref() (more...)

Follow-ups:
Re: Re: Re: A possible race condition in Packet::invalidateHeader()
Hi Atul, I read the article you referred to. It was quite interesting! If I understood correctly, it is recommended that all thread shared data be volatile. volatile is not needed (more...)