Re: [gnugo-devel] GNU Go as an oracle

[Dave Denholm]

Andrew Derrick Balsa <address@hidden> writes:

> Hi,
> 
> On Thursday 07 November 2002 10:26, Dave Denholm wrote:
> [...]
> > pthreads is the posix threads package. There are various implementations
> > for linux and win32, so that would probably be the most portable approach.
> > And of course solaris, hpux, aix etc offer pthreads. Don't know about
> > macos.
> >
> > At least one of the implementations of pthreads on linux uses clone(),
> > but it isn't strictly conforming to the posix standard. It is usually good
> > enough for most applications, though. There are other pthreads libraries
> > around which are entirely user mode.
> 
> Here is a list of multithreading libraries:
> http://www.gnu.org/software/pth/related.html
> >

More interesting is a set of API's portable across unix and non-unix operating 
systems.


> >
> > However, FWIW, my own experience is that introducing threads always makes
> > things over-complicated. It is very difficult to get threaded programs
> > correct.
> 
> It's not trivial, but this team has a bunch of excellent programmers that 
> certainly can handle it.
> >

But it's a distraction. And threads tend to behave very differently on
different o/s-es.

> > Eg if we start a thread to look ahead, we have to be able to terminate
> > it. Which means we need some sort of handshake to make the main thread
> > know when the helper has terminated etc.
> 
> POSIX pthreads provides a rich set of standard calls for synchronization. 
> >

But it's harder to get the attention of a thread that isn't expecting it...


> > On unix, this is a lot easier to manage with a child process. Unfortunately
> > that's not portable, of course.
> 
> Hmmm, I am not sure it's easier with child processes. My suggestion would be 
> to try with pthreads first. Having a single address space is the big 
> advantage, it saves a lot of work.
> 

I would say the contrary. It's easier with a child process because
fork()  copies the data and so the child has a private set of data.
When we decide to kill it, we can just sent it a kill, and don't have to
wait for it to restore the shared data to a good state.

With a thread, we have to wait until the thread has repaired any shared
data structures before we can proceed.


it does of course depend on what the helper is for. If we do want it to
update some shared data, then yes, a thread is perfect. But if it's to
try something speculative, which might be abandoned, then a process may
be easier.


dd
-- 
address@hidden          http://www.insignia.com