Winboard Forum

Hi all,

As some of you may recall (see the thread named "Windows thread question"), I have had difficulties making my program work with more than 2 threads in Windows, although it works fine in OS X and Linux. When compiled with support for more than 2 threads, the program just hangs instantly when a search is started. Unfortunately I know very little about Windows threads and have no Windows computer for compiling and testing my program, which makes the problem rather tricky to debug.

I have now made another attempt to fix this annoying problem, but I need somebody else to test it for me. I would therefore appreciate if someone with the Microsoft compiler could download my current source code, try to compile a Windows binary, and check whether it works.

Tord

Here's the bad news. There is really no difference between windows and linux, except for the semantics of actually creating a thread. But the timing is definitely different, and it is most likely exposing a timing hole you have not anticipated. I had similar issues in early crafty versions. They always turned out to be some sort of unexpected timing. After creating a thread, one gets to point A way before the second. Or they both get there at the same time where in linux that did not happen, etc. This can be fun to find...

Tord Romstad wrote:Hi all,
I have now made another attempt to fix this annoying problem, but I need somebody else to test it for me. I would therefore appreciate if someone with the Microsoft compiler could download my current source code, try to compile a Windows binary, and check whether it works.

Tord

So far it runs ok I want to do abit more testing with it and will email the binary.


Bryan

bob wrote:Here's the bad news. There is really no difference between windows and linux, except for the semantics of actually creating a thread.

There are a number of other differences. Most of them are really trivial, but they can still cause silly little bugs when you cannot test the Windows code.

One of the little differences, and the one which most likely caused my problem (if my most recent version works, and according to Bryan it seems that it does) is that there is no direct equivalent of pthread_cond_t and pthread_cond_broadcast() in Windows. On POSIX systems, I solve the problem of putting the helper threads to sleep when the program is idle by letting them block on a condition, and wake them up again with a call to pthread_cond_broadcast() when I start a new search. In Windows, I use a pair of functions called WaitForSingleObject() and SetEvent() instead. I didn't know exactly how these functions worked, and it turned out that the way I was using them, only one of the helper threads would wake up from sleep. This would cause the program to hang at the first split point.

Tord

Bryan Hofmann wrote:

Tord Romstad wrote:Hi all,
I have now made another attempt to fix this annoying problem, but I need somebody else to test it for me. I would therefore appreciate if someone with the Microsoft compiler could download my current source code, try to compile a Windows binary, and check whether it works.

Tord

So far it runs ok I want to do abit more testing with it and will email the binary.

Great news! Thanks!

Tord

Tord Romstad wrote:

Bryan Hofmann wrote:

Tord Romstad wrote:Hi all,
I have now made another attempt to fix this annoying problem, but I need somebody else to test it for me. I would therefore appreciate if someone with the Microsoft compiler could download my current source code, try to compile a Windows binary, and check whether it works.

Tord

So far it runs ok I want to do abit more testing with it and will email the binary.

Great news! Thanks!

Tord

The 32 & 64 Bit compiles have been sent to you.


Bryan

Tord Romstad wrote:One of the little differences, and the one which most likely caused my problem (if my most recent version works, and according to Bryan it seems that it does) is that there is no direct equivalent of pthread_cond_t and pthread_cond_broadcast() in Windows. On POSIX systems, I solve the problem of putting the helper threads to sleep when the program is idle by letting them block on a condition, and wake them up again with a call to pthread_cond_broadcast() when I start a new search. In Windows, I use a pair of functions called WaitForSingleObject() and SetEvent() instead. I didn't know exactly how these functions worked, and it turned out that the way I was using them, only one of the helper threads would wake up from sleep. This would cause the program to hang at the first split point.

Tord

Tord, I took a look, and I noticed that you have created your events with automatic resetting of the event. This means, that when an event is caught by a WaitForSingleObject its state is automatically switched to "unset". Probably you will want a manual reset of the events for broadcasts and better control, so try calling:

Code: Select all

SitIdleEvent[i] = CreateEvent(NULL, TRUE, FALSE, NULL);
instead of
SitIdleEvent[i] = CreateEvent(0, FALSE, FALSE, 0);


But then you need to call ResetEvent() yourself to flip it to the unset state.

Sune Fischer wrote:Tord, I took a look, and I noticed that you have created your events with automatic resetting of the event. This means, that when an event is caught by a WaitForSingleObject its state is automatically switched to "unset". Probably you will want a manual reset of the events for broadcasts and better control, so try calling:

Code: Select all

SitIdleEvent[i] = CreateEvent(NULL, TRUE, FALSE, NULL);
instead of
SitIdleEvent[i] = CreateEvent(0, FALSE, FALSE, 0);


But then you need to call ResetEvent() yourself to flip it to the unset state.

Hi Sune,

Thanks for the suggestion. If I understand the Windows threads API correctly (but of course it is very possible that I don't), my current code should work OK. If it turns out that there are still problems, however, I'll give your code a try.

Tord

I don't use any condition waits or anything else from the pthread() library, so those are not issues for me at all. I do all my IPC stuff through shared memory variables and avoid the system overhead which is considerable with the pthread stuff.

bob wrote:I don't use any condition waits or anything else from the pthread() library, so those are not issues for me at all. I do all my IPC stuff through shared memory variables and avoid the system overhead which is considerable with the pthread stuff.

That's mostly what I do, too. I use condition waits only when the program is not searching. During the search, the only thing I use from the pthreads library is mutex locks (which are not measurably slower than spinlocks for me, as previously discussed).

Tord