Threading each moverecord sounds like a smart thing to do. >> Which library do you use? pthreads? glib threads? > > Initially I've coded the multi-threaded calls directly using > the windows API, it should be easy to convert this to pthreads > (or maybe glib) - there are only 5 or so lines of code using > multi-threaded functions.
I think I will prefere glib threads. That will make porting simple. Windows API will limit things to Windows, pthreads will limit things to POSIX systems. (Though there is a pthread port to Windows.) Maybe some #ifdef if we can't decide. >> (I remember I once tried threading in the evaluations >> functions and made one tread each dice roll in the >> lookahead. That failed completly.) > I did consider the evaluation functions (as it would be the ideal > solution in one sense - i.e. it would multi-thread everything in one > go), they're not great candidates for multi-threading though. My problem was joining threads. I believe I used a static counter to generate a thread ID for each tread, the problem was when I then should join the threads, some threads did never end/return. I'm not exactly sure what went wrong, but I belive there was a problem with the counter for thread ID. There is also the drawback that this method for threading will not improve 0-ply analysis/evaluations. > I'll try and check the initial code in tonight - I'll add a > USE_MULTITHREADED guard to the new code. I won't be able to look at this tonight. (I have an important meeting at the local pub.) Maybe later this weekend. I have a lot of things to install to the new box as wll, before I'm up and running. -Øystein _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
