[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnuchess-5.07 threading problem

From: Krister Walfridsson
Subject: Re: gnuchess-5.07 threading problem
Date: Tue, 16 Mar 2004 00:24:54 +0100 (MET)

Hi Simon,

On Thu, 11 Mar 2004, Simon Waters wrote:

> Care to name the platform? (I'm just curious).

This was on NetBSD 1.6.

> Better yet can we spot non-preemptive thread library at config time?

I don't know (but it should be possible to create an ugly configure

The context in which I saw the problem is the NetBSD pkgsrc
(http://www.pkgsrc.org) that is a framework for packaging and
building software.  Pkgsrc is formally a NetBSD project, but it
works on nearly all Unix-like operating systems.

Pkgsrc sets up a unified environment when building packages.  This
environment includes the pthread library from the operating system,
or the GNU PTH thread library for OS that do not have native threads.

So testing for _POSIX_THREAD_IS_GNU_PTH solves my problem.  (I don't
think there are many other non-preemptive thread libraries out there...)

> > This can be solved with an explicit sched_yield() as in the patch below,
> > although you might want to find a better place to place that call, in
> > order to give a more responsive user interface...
> In "Search" in search.c every so often we do some housekeeping.
> look for..
> >> if (((flags & PONDER) || SearchDepth == 0) && (NodeCnt & TIMECHECK) == 0)
> This is probably the right place and frequency to do a yield, but we
> might want to do it only when "NodeCnt & TIMECHECK" is true but other
> end conditions are false.

Hmm. I'm not sure which end conditions you mean, but the patch below is
definitely more responsive...

--- src/search.c.orig   Tue Mar 16 00:04:30 2004
+++ src/search.c        Tue Mar 16 00:07:48 2004
@@ -546,6 +546,10 @@
               SET (flags, TIMEOUT);
+      else if (NodeCnt & TIMECHECK)
+        sched_yield();

 /*  The following line should be explained as I occasionally forget too :) */
 /*  This code means that if at this ply, a mating move has been found,     */

> We still have a known bug in the handling of games being reset whilst
> the machine is thinking, does this cause a problem when you have no
> pre-emptive threads?

I have not seen that problem, but I have OTOH not tried it more than
a couple of moves... :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]