Quote:Original post by CGameProgrammer
I did it that weird way because I couldn't find a good way in Windows of waiting for a thread to finish; the available functions seemed weird.

You can synchronize on the thread handle. When the thread exits its handle will be signalled so you can call WaitForSingleObject() or WaitForMultipleObjects() on the actual Threads[] variables. Your windows implementation is extremely badly written. Assuming your other two threads are completely CPU bound and have nothing to wait on, your original thread will take up 33% of the process' CPU time. I'm surprised you even see a small speedup, I'd expect this code to run longer than the single threaded version.

Grrr, GDnet login is F'ing arund with me, that was me ^^^^^^^^^

Hmm, even I can see that you need a sleep in that while loop in your main function.

That first AP post was quite insightful.

50% speed boost might seem high for the linux version, but I've always understood that Windows' threading isn't particularly grand.
I think that an extra thread in linux may actually get you more total CPU time for your program (equal amount per thread of equal priority perhaps).
Whereas under windows your single thread already took most of the processor time, and your second one meant that you had to divide it up.

Ysaneya: I have a theory why it's doing that, which I'm working on fixing. I think the problem is the two threads probably have wildly different workloads. They both evaluate the same number of ships, but ships that aren't moving are evaluated much quicker than moving ships, so they could be doing 16 moving ships in one thread and 16 stationary ones in the other. I'm changing the code to fix this and should have an updated build Wednesday.

Hey Ysaneya, I've updated GDomin.zip and I think this version will run much faster on your multi-CPU setup. Please try it out. With just hyper-threading, there doesn't seem to be a speed-up, but it's probably just not the type of thing that benefits from HT.

You need to use a semaphore to syncronize the execution of your worker threads.
They should only run when there's work for them to do.

Creating and destroying threads is expensive. I'd create a thread pool (with 2 threads) and bump the semphore by 2 when it's time to do the physics calculations. Then wait for the semaphore count to return to 0; each worker thread should reduce the count when it's done with its calclations. The main thread could make the first work split and configure some data structure with the part of the world each thread needs to handle. This ensures everything runs smoothly. You have to make special OS calls that put your threads to sleep until they are told it's time to wake up. The worker threads need to sleep until the semaphore is incremented by the main thread and the main thread needs to sleep until the count returns to 0. You might need to use two semaphores to make that happen; one to queue the the worker threads and another to tell the main thread when they are done.

Now with hyper-threading, I would not expect a performance increase with two busy threads. Hyper-threading works best if the competing threads are waiting for data most of the time.

Neat idea, Magmai. So I create two threads and a semaphore (initialized to 0) initially, and the threads sleep until the semaphore is above 0, and then they decrement it and do their calculations. So when it's time for the calculations, the main thread just sets the semaphore to 2 and waits for it to be 0 again. That makes alot of sense.

EDIT: I started to code this, but I am confused on how to implement it in Windows. On initialization, I create the two threads, and I call:

ThreadSignal = CreateSemaphore( NULL, 0, 2, NULL );

So that creates a semaphore with an initial value of 0 (and max of 2). The body of the thread function looks like this:

while( 1 ){    WaitForSingleObject( ThreadSignal, INFINITE );//  Do AI}

So that should wait for ThreadSignal to be greater than zero, then decrement it and proceed with the AI. The main thread does this when it's time to run the AI:

ReleaseSemaphore( ThreadSignal, 2, NULL );

Setting the semaphore to 2, thus allowing the threads to run. But my problem is the main thread needs to wait for the semaphore to be 0, and I don't know how to do that. Also, it seems like it could be theoretically possible for a single thread to decrement the semaphore twice before the other thread ever gets a chance to look at it. So I don't know how the semaphore code is supposed to work.

Drew_Benton: I do not, but it's worrying that you're having problems... all statistics are reported correctly for me. I assume you downloaded it after I made my lastest post? Oh, also it would be useful to know what OS you're using.

[Edited by - CGameProgrammer on December 17, 2004 3:52:31 AM]