- Forum
- General C++ Programming
- std::thread fun
std::thread fun
I came to a situation where I believe spawning a new thread is ideal. Took me a bit to even get it to compile, was creating it wrong apparently. Got it compiling now, but the program crashes immediately with:
What am I doing wrong here?
EDIT:
Eh I guess this should be in *nix, but it seems like nobody goes there anyway :)
It's an SFML application. I seem to remember reading somewhere about some rules with what can be in separate threads and what can't, but I can't find that again.
[xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. Pong: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. Aborted (core dumped) |
|
|
What am I doing wrong here?
EDIT:
Eh I guess this should be in *nix, but it seems like nobody goes there anyway :)
It's an SFML application. I seem to remember reading somewhere about some rules with what can be in separate threads and what can't, but I can't find that again.
Last edited on
Eh figured it out. Had this thread inadvertently handling the rendering also. I'm pretty certain that's what the SFML stuff I found said...
But, exiting this program still yields:
My only experience with threads has been in Java, and they are incredibly easy over there. So I'm sure I'm not handling something correctly. I have a feeling that it has to do with input handling not being in this logicThread. So when I exit out of the application, the thread doesn't die properly. If there isn't enough info, I'll push out the code to my github for criticism
But, exiting this program still yields:
terminate called without an active exception Aborted (core dumped) |
My only experience with threads has been in Java, and they are incredibly easy over there. So I'm sure I'm not handling something correctly. I have a feeling that it has to do with input handling not being in this logicThread. So when I exit out of the application, the thread doesn't die properly. If there isn't enough info, I'll push out the code to my github for criticism
terminate at exit may be caused by you forgetting to join the thread
(logicThread.join();)
If I understand it correctly, std::thread::join() is blocking? That seems to beat the purpose of the thread.
Ooh unless I stick that in the exit event handling...
Ah that isn't gonna work. I have no way of notifying the thread that it should be done..
Ooh unless I stick that in the exit event handling...
Ah that isn't gonna work. I have no way of notifying the thread that it should be done..
Last edited on
closed account (o1vk4iN6)
Well from the context of what was given in the OP it seems like you are creating another thread to do the logic for a pong game. I don't think you really need to for such a simple game, you are just over complicating the game and obviously coming across some of the pains of multi-threading.
In order to render the window you need to complete the logic, so rendering and logic will never be executed simultaneously so there is no point in separating them into two different threads. You could use threading to do something like, split the world into sections and have different threads handling the collision for each section. In a way such that the objects in thread 1 have zero possibility of colliding with objects assigned to thread 2. Obviously you could research more into what threading can be optimal for in game development.
In order to render the window you need to complete the logic, so rendering and logic will never be executed simultaneously so there is no point in separating them into two different threads. You could use threading to do something like, split the world into sections and have different threads handling the collision for each section. In a way such that the objects in thread 1 have zero possibility of colliding with objects assigned to thread 2. Obviously you could research more into what threading can be optimal for in game development.
Well I'm kind of working on a framework for more complicated stuff in the future.
It seems like handling game logic, rendering, and input in a single thread would be unwieldy.
It seems like handling game logic, rendering, and input in a single thread would be unwieldy.
closed account (o1vk4iN6)
You are over complicating it, yes logic and rendering are relatively slow processes but putting them into separate threads isn't going to provide any performance boost. When your rendering thread is processing, your logic thread will be waiting for it to finish and vice versa. That waiting might actually make your program over all slower, and most definitely complicate the design.
Input is another thing, the only reason you would want to put it on a separate thread is if the logic/rendering thread is running slow (lags, giving you a fps drop) and you want to still capture input during that time. As an example, i forget which version of Photoshop, but if you create a new image with a fairly large resolution and use a relatively large brush and try to draw an "arch". You will actually end up getting something more like 2 dots if you draw it quickly enough because it doesn't capture input on a separate thread and the logic for drawing such a big brush being relatively slow caused some input not to be captured.
Just don't do premature optimization. If necessary you could do something like, "OK" objects for use in physics. eg objects that were already drawn on the screen or that were culled and not drawn can be used for physics calculations and such. Though I highly doubt you will need to do something like that.
Input is another thing, the only reason you would want to put it on a separate thread is if the logic/rendering thread is running slow (lags, giving you a fps drop) and you want to still capture input during that time. As an example, i forget which version of Photoshop, but if you create a new image with a fairly large resolution and use a relatively large brush and try to draw an "arch". You will actually end up getting something more like 2 dots if you draw it quickly enough because it doesn't capture input on a separate thread and the logic for drawing such a big brush being relatively slow caused some input not to be captured.
Just don't do premature optimization. If necessary you could do something like, "OK" objects for use in physics. eg objects that were already drawn on the screen or that were culled and not drawn can be used for physics calculations and such. Though I highly doubt you will need to do something like that.
Last edited on
XInitThreads();Call it before creating the threads. I had the same error pop up when I did that.
| putting them into separate threads isn't going to provide any performance boost |
Multithreading for separation of concern (with no immediate performance effects) is not all that rare - it can make programs easier to reason about and maintain. Granted, this doesn't seem like a convincing case for that either.
OP wrote:
So why not use one of the sf::Thread classes instead and keep it more cross platform?
| It's an SFML application. |
So why not use one of the sf::Thread classes instead and keep it more cross platform?
Even Laurent recommends just using std::thread if the compiler supports it.
Should be just as cross platform as std::thead.
Should be just as cross platform as std::thead.
^ That's interesting to note, I wonder why he wouldn't put a foot note to that effect in the documentation. And yeah, MSVS doesn't make a noticeable effort to support 11x until version 2013.
Topic archived. No new replies allowed.