Jump to content

  • Log In with Google      Sign In   
  • Create Account

snt there a way to make threads of winapi safe ?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 RichardBurns_206   Members   -  Reputation: 100

Like
0Likes
Like

Posted 16 January 2012 - 10:24 AM

the problem is when i create a thread i cant make sure its dead before i reexecute its clone. :P
is there a way to make sure a winapi Createthread is dead safely ?
im asking because when i use this on winapi allmst allways there is unpredictable crashes. that happens much common when using winapi spesific functions.
and on msdn most programmers commented that createthread is a depricated function and we hawe to use threadind the old way :D ?
is that true ? isnt there a way to make threads of winapi safe ?

Sponsor:

#2 Evil Steve   Members   -  Reputation: 1982

Like
0Likes
Like

Posted 16 January 2012 - 10:28 AM

When a thread exits, the handle becomes signalled. So you can use WaitForSingleObject() on the thread HANDLE to wait for the thread to become signalled, or to poll the handle.

Steve Macpherson
Systems Programmer

Rockstar North


#3 rip-off   Moderators   -  Reputation: 8222

Like
1Likes
Like

Posted 16 January 2012 - 11:36 AM

Why are you trying to "reexecute" a "clone" of the thread? Thread creation is expensive enough that it should be avoided where possible. You could perhaps change the logic so that the thread isn't 100% tied to the task, and that the thread can pull tasks from some thread-safe task queue.

#4 RichardBurns_206   Members   -  Reputation: 100

Like
0Likes
Like

Posted 16 January 2012 - 05:24 PM

Why are you trying to "reexecute" a "clone" of the thread? Thread creation is expensive enough that it should be avoided where possible. You could perhaps change the logic so that the thread isn't 100% tied to the task, and that the thread can pull tasks from some thread-safe task queue.

the thread i thinked of doues gui part in background for performance cases ( loading icons of objects) that way it looks far better :P . and sometimes it executes repeadedly so i hawe to kill copies to not let owerloading .
threading looks like a good way to not wait for somethin you may or maynot need . ie icons :P

#5 compscialien   Members   -  Reputation: 104

Like
0Likes
Like

Posted 16 January 2012 - 09:46 PM

You might want to look at a lock to prevent the multiple creation, rather than have the thread die and be recreated. Actually, with C++, you could look at a singleton possibly, since this would be one of those cases where a singleton would be useful (from what I can guess from your description).

EDIT: I don't write a lot of mutli-threaded code, but I believe you want to use a mutex.

#6 Endurion   Crossbones+   -  Reputation: 3575

Like
0Likes
Like

Posted 17 January 2012 - 02:06 AM

Also, don't do GUI stuff (Win32) from a different thread as to where you created the windows/controls in. PostMessage will be safe, SendMessage might end in dead locks.
Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

#7 rip-off   Moderators   -  Reputation: 8222

Like
0Likes
Like

Posted 17 January 2012 - 03:49 AM

the thread i thinked of doues gui part in background for performance cases ( loading icons of objects) that way it looks far better. and sometimes it executes repeadedly so i hawe to kill copies to not let owerloading .

Then using a single background thread with a task queue might be better. Dynamically spawning threads will probably be detrimental to performance.

Also don't forget to ask regular people what they think of icons loading asynchronously. I think that lots more companies would be doing it if it "looked better" to the average user! It has been my experience that UIs that "jump" or change without interaction are distracting and more difficult to use.

Finally Windows already provides a mechanism for asychronous I/O, I/O completion ports. The boost library provides a wrapper, called asio.

In any case, think very carefully before you introduce asynchronous behaviour into your application. It is notoriously difficult to get right. Unless you are extremely disciplined, you will have an unstable and buggy application. Who cares how fast it loads, if it is unreliable?




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS