Re: [Bug-gnubg] GNUbgW speedingup50%

[Gary Wong]

On Fri, Jun 28, 2002 at 07:35:00PM +0000, Joern Thyssen wrote:
> For MPI (and beowulf) there would be no problems as gnubg would run as
> separate processes on each computer on the distributed system. 

Right.

> For implementation with threads we would have to introduce a write lock
> on the cache, or give each thread its own cache.

Yes.  My guess is that a shared cache would speed up evaluations by
more than the lock contention will cost, so that it will be better to
share one cache, but either way would work.

> The background analysis can be performed with threads. One way to solve
> these problems would be to add a lock to all moverecords, so only one
> thread at a time could write to that particular moverecord.
> 
> All processes that wants to write (and read?) a particular moverecord
> would have to acquire the lock first. 

True, but there's more to worry about than just locks on shared data.
My guess is that more problems in practice would arise from
co-ordination issues when the user changes something while other
threads are running, e.g. making a move and then taking it back while
background auto-analysis is still running, changing evaluation
parameters while something is running (since the evalcontext
parameters are all pointers), etc.  I expect there are lots of cases
like that below the surface that all eventually need worrying about.

Cheers,
Gary.
-- 
   Gary Wong           address@hidden           http://www.cs.arizona.edu/~gary/