Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

foofightr

Multi-threading with objects

This topic is 5494 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I don't have much experience with using threads on a per-object basis. By object, I mean an instantiation of a C++ class, not a Win32 API notion of objects. I need a way for objects to have their own threads that modify members of the object. I will pass in 'this' as the LPVOID argument of the thread so that it knows about the object it has to play with. I thought a bit about it and here are 2 ways I thought of doing it. 1) find out what members the thread needs to modify, and make them public. Not that great a solution. Making accessor functions would not make it any cleaner, as the outside world still has access to members that really shouldn't be public. 2) hard-code offsets of the members that the thread needs to modify, and write directly to ('this' + offset). It breaks encapsulation, but so what. The outside world still sees these members as being private, so at least the ugliness is contained within. Are there better alternatives? [edited by - foofightr on November 30, 2003 8:14:31 PM]

Share this post


Link to post
Share on other sites
Advertisement
Don''t confuse control flow with data flow. It''ll only lead to tears.

A thread is a function call. In terms of data access, that''s all it is. In C++, it has to be either a global function, or a class-static function. If a thread is "owned" by an object, the latter is really a better solution.

Watch this:


class A
{
static void MyStaticFunc(void* data) { reinterpret_cast<A*>(data)->MyFunc();
void MyFunc() { ... }
};


Now MyStaticFunc can be used as a function pointer. Pass in the "this" pointer of an A, and that A will have its MyFunc() called by the thread.


"Sneftel is correct, if rather vulgar." --Flarelocke

Share this post


Link to post
Share on other sites
umm, you cant use reinterpret_cast on void pointers, as the compiler cant assume anything about the memory pointed to by a void pointer, you would have to use static cast instead.

According to stroustrup anyway.. (I only know this cos i read it this morning in the train )

"The compiler cannot assume anything about the memory pointed to by a void*. This implies that dynamic_cast - which must look into an object to determine its type - cannot cast from a void*. for that a static_cast is needed."

Share this post


Link to post
Share on other sites
Hello foofightr,

I would do something along the lines of what Sneftel says.
But I would do it by way of a base class that would handle the
creating of threads and running a function. That way you can decide if you want your class to be threaded or not by simple inheritance, as long as your class was a run methed defined.

basic idea here is you can simple make a class thread able by inheriting form the thread class, and create a method that the base thread class would call ie like a run() method.

so you have this.

class A // thread class
{
static void MyStaticFunc(void* data); // this becomes the method form creating the thread using data which was the this passed in by start()
void start(); // this would call the MyStaticFunc with this as the data
virtual void MyFunc() = 0; // the deriving class must define the run method
};

class B : public A
{
void MyFunc()
{
// code to run.
}
}

Then what you do is create a class B, which at creation is not in a thread yet, this allow you to do things in your class like set parameters before it becoming a thread.
Then when your ready for it to be a thread call start() and then away you go it a thread.

Lord Bart

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!