views:

86

answers:

2

I want to make a simple GUI API. Essentially the way it will work is the gui widget is basically a thread in an infinite loop. The thread has a pointer to the widget's class. The way I want it to work is basically similar to WinAPI. I would do something like this:

textbox->SendMessage("Click",args); 

which is then added to its queue for processing. Eventually this will call a pointed function which would be the click event handler. Another thing I want to be able to do is safely get and set stuff in the class, without having to worry if the worker thread is using it. For example, if I send a message (which adds to a queue) while the worker is dequeing this might cause trouble. I'm using boost::thread. What exactly should I do for my situation?

Thanks

A: 

This sounds a lot like the "Active Object" pattern, where an object runs calls to its methods in its own private thread.

Since you're using C++, you may find Herb Sutter's Effective Concurrency article on active objects useful.

Nick Meyer
you mean, "that sounds a lot like the "active object" anti-pattern.
Chris Becke
Fire extinguisher at the ready!
graham.reeds
@Chris, are you simply agreeing with Ryan that this is not a good approach for GUI development, or are you objecting to the "active object" pattern in general? Can you elaborate?
Nick Meyer
I object to the active object pattern in general - at least when expressed as a "thread per object" (and implemented in a traditional language where a thread is an actual OS thread). In this case its a cargo-cultesque approach to achieving concurrency. In reality, OS threads typically have high costs associated with creating and keeping many around and calling between them so scalable software tries to keep a parity between active threads and CPU cores.
Chris Becke
+1  A: 

Is there a reason you're going down this path for GUI development?

There's a very good reason nearly all GUI libraries rely on a single thread for managing 'widgets'. Multithreading is hard; when writing controls with a large exposed interface you're going to need to be exceedingly careful in how you design it. As the number of threads (widgets) grows you'll also face scalability problems when you get near the operating system's thread limits, or failing that, you increase the load on the scheduler such that some threads begin to starve.

My advice would be to redesign with a typical single-threaded message pump that pushes input events into widgets and pulls out their resultant state.

Ron Warholic
Then would it be suitable to simply have 1 thread for all my widgets? I'm making this for my game, would it be even better just to have the gui on the same thread as game rendering?
Milo
How big of a game is this? Is this a solo project? If this is for a solo game, focus on making the game not the engine. Do everything on one thread and focus on making clear, well-defined boundaries that may allow you to optimize rendering later. Many small team (or solo) game developers fail when they try too hard to create a large engine infrastructure instead of a real game. If this is for a larger project or *purely* for an API/engine; use a separate thread, render to an off-screen surface and have the render thread pull from this when it is marked as dirty.
Ron Warholic
The key is: keep the the GUI on a single thread (preferably the same thread as gameplay processing) so you can worry about actually writing widgets and not debugging race conditions.
Ron Warholic
alright thanks a lot :) I will follow your advice and I think this will work out best
Milo
Good luck with it! :D
Ron Warholic