Discussion about "Threads, Events and QObjects" article

Page  
3

December 21, 2010

Volker Volker
Ant Farmer
5428 posts
Franzk wrote:
Volker wrote:
but I doubt there’s any T-Shirts to win :-)
Huh, imagine T-shirts stating something about your re-entrancy…

What a about

“I’m a male – I’m not thread safe!”

[Edit – ok, a bit offtopic now :-) Volker]

December 21, 2010

Franzk Franzk
Lab Rat
837 posts

“I am NOT re-entrant”

 Signature 

“Horse sense is the thing a horse has which keeps it from betting on people.”—W.C. Fields

http://www.catb.org/~esr/faqs/smart-questions.html

December 30, 2010

changsheng230 changsheng230
Lab Rat
128 posts

Qt also requires that all objects living in a thread are deleted before the QThread object that represents the thread is destroyed; this can be easily done by creating all the objects living in that thread on the QThread::run() method’s stack.

Do you mean that
this can be easily done by deleting all the objects living in that thread on the QThread::run() method’s stack.
?

 Signature 

Chang Sheng
常升

December 30, 2010

Panke Panke
Lab Rat
42 posts

Object created on the stack of QThread::run() should get destroyed automatically, when it goes out of scope.

December 30, 2010

peppe peppe
Ant Farmer
1028 posts

changsheng230 wrote:
Qt also requires that all objects living in a thread are deleted before the QThread object that represents the thread is destroyed; this can be easily done by creating all the objects living in that thread on the QThread::run() method’s stack.

Do you mean that
this can be easily done by deleting all the objects living in that thread on the QThread::run() method’s stack.
?

No: I mean that if you do

  1. MyThread::run()
  2. {
  3.     Object obj1, obj2, obj3;
  4.     OtherObject foo, bar;
  5.     /* ... */
  6. }

All those objects will:

  • be created on run()‘s stack;
  • be living in the “MyThread” thread;
  • get automatically destroyed immediately before run() returns (thus, terminating the thread).

 Signature 

Software Engineer
KDAB (UK) Ltd., a KDAB Group company

December 30, 2010

Panke Panke
Lab Rat
42 posts

Remember that instance will be a dangling pointer after run() returns. One solution
would be the use of smartpointer.

  1. MyThread::run()
  2. {
  3.     Class* instance = new Class;
  4.     /* ... */
  5. }

January 4, 2011

Wolf P. Wolf P.
Ant Farmer
354 posts

Another solution would be, to create objects as children of objects that will be destoyed. (But choose objects for parentship that reside in the same thread.)

February 23, 2011

kevinSharp kevinSharp
Hobby Entomologist
12 posts

There seem to be two copies of this article now. This one: https://developer.qt.nokia.com/wiki/Threads_Events_QObjects has a revision history going back to Pepe’s original post on 10 Dec through Alexandra’s name change on 10 Feb. This one: https://developer.qt.nokia.com/wiki/ThreadsEventsQObjects was posted by Volker on 23 Feb under the old name. Based on a quick doc compare, I think the content of the two are identical except for the title.

@Volker: are there other changes in your 23 Feb edit that I’m not seeing? I’d like to consolidate the two back to the (new) name.

 Signature 

—kevin

February 23, 2011

Volker Volker
Ant Farmer
5428 posts

The two articles are identical. My “version” (that without the underscores) is only a link to the actual article. The reason is, that the old version of the link is referred in some other articles and in a blog entry.

Unfortunately it does not redirect to the actual article but pulls in its content and it does not leave a message of doing so.

February 23, 2011

kevinSharp kevinSharp
Hobby Entomologist
12 posts

OK, tks. That makes sense. I’ve wondered about inbound links as we rename articles. I have done a few searches to try and catch broken links, but I know I miss some.

 Signature 

—kevin

March 4, 2011

Noah Noah
Lab Rat
12 posts

Not sure if the documentation has ever been updated, but it’s my understanding that subclassing QThread is no longer recommended. http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/

March 4, 2011

Gerolf Gerolf
Robot Herder
3253 posts

That is wrong, it depends, what you are doing…

Me, for example,, I often have worker threads, that do not use signal / slot, but that are waiting on wait conditions and have order queues which are filled by the client via special methods. These threads overwritre run (as the yhave special handling there) and implement synchronisation on their own.

Aslo if you have pre/post conditions in your threads event loop (like COM initialization on Windows), you have to overwrite run. So there are many scenarios where it makes sense…

 Signature 

Nokia Certified Qt Specialist.
Programming Is Like Sex: One mistake and you have to support it for the rest of your life. (Michael Sinz)

March 4, 2011

James G James G
Lab Rat
2 posts

Great article peppe. One area you didn’t get into was implicitly shared objects. This is a tricky subject and one that I wrote about before:

http://www.folding-hyperspace.com/program_tip_15.htm

While I don’t know if my analysis is absolutely correct, I think this is another area where the official Qt documentation needs improvement. They totally missed that QDateTime is implicitly shared and when I tried using it in threads I found the problem noted above. The same thing applies to list objects like QList. Passing these between threads in signals and slots might be a problem, but I haven’t explored this yet. I simply protect all such objects with QMutex and haven’t seen any problems.

Also, here is a more complete article I wrote on getting good timing in threads:

http://www.folding-hyperspace.com/program_tip_14.htm

The Qt_RealtimeIO_App example download shows several ways of doing timing and how accurate or inaccurate it can be.

A more complete list of soft realtime related articles is at:

http://www.folding-hyperspace.com/program_tips.htm

I will read your article more carefully in time and see if I can suggest any other improvements.

And I might say it is really fun to program up a big numerical program using QConcurrent and run it on an Intel i7 with 8 cores and watch it speed up x8 times. Qt rocks!

March 5, 2011

peppe peppe
Ant Farmer
1028 posts

Dear James,

your analysis is incorrect. QString, QDateTime and many others (possibly all?) implicitly shared classes clearly state in the documentation that they’re not thread safe. Or, better, they say they’re only reentrant, therefore you can’t assume they’re thread safe. You are describing a race condition between two threads accessing the same object at the same time, which causes a major problem.

That is, suppose you have something like:

  1. SharedObj *obj = new SharedObj;

Then thread 1 is executing

  1. delete obj; // runs the dtor

And at the same time thread 2 is executing

  1. SharedObj obj2(*obj); // runs the copy ctor

“obj” is now being accessed from two threads at the same time: from the obj2 copy ctor and from its dtor. This violates the contract: SharedObj is not thread-safe; up to one thread can access a certain instance at any time.

What instead implicitly sharing lets you to do is, for instance:

  1. SharedObj obj1(...);
  2. SharedObj obj2 = obj1;
  3. /* now thread1 accesses obj1 while thread2 accesses obj2 */

The two objects will safely share the internal data (a memory optimization), but as soon as one thread tries a non-const access, the object detaches its internal data performing a deep copy. This is guaranteed to work (and indeed does).

 Signature 

Software Engineer
KDAB (UK) Ltd., a KDAB Group company

March 6, 2011

Franzk Franzk
Lab Rat
837 posts

peppe wrote:

That is, suppose you have something like:
  1. SharedObj *obj = new SharedObj;

Then thread 1 is executing

  1. delete obj; // runs the dtor

And at the same time thread 2 is executing
@
SharedObj obj2(*obj); // runs the copy ctor
@

Indeed so. Note that this is an approach that in almost all cases shouldn’t be used for implicitly shared classes. They do the memory tricks so you don’t have to.

 Signature 

“Horse sense is the thing a horse has which keeps it from betting on people.”—W.C. Fields

http://www.catb.org/~esr/faqs/smart-questions.html

Page  
3

  ‹‹ Wiki Addons with only links      [Suggestion] Wiki Comment ››

You must log in to post a reply. Not a member yet? Register here!