RE: [Gcl-devel] Re: a few questions about the status and directionofGCL

[Mike Thomas]

Hi Camm.

| > Another alternative might be pthreads, for which a Win32 subset exists.
| > This is potentially tricky if there are semantic differences between the
| > Unix and Windows versions of pthreads (usually are with Unix emulation
| > libraries I have seen).

| Glad you said this, because pthreads would have been my choice for
| Linux as well.  Am still reading the helpful openmcl doc posted
| earlier and am hoping it is similarly based too.

OK, we'll call that Plan A - I haven't used pthreads myself and I suppose we
need also to consider portability of pthreads to platforms other than Linux
and Windows.  The Windows port is described here:

  http://sources.redhat.com/pthreads-win32/

and the all important limitations here:

  http://sources.redhat.com/pthreads-win32/conformance.html

For Plan B, I'll just write equivalent code with the normal Windows thread
API functions which actually work perfectly well and would probably be more
efficient in the long run - it would just be good to retain commaon source
across the platforms while we have such limited person-hours available.

It would be great if we can initially stick with simple
concurrency/parallelism primitives which can be implemented at the low level
in various ways (eg MPI, pthreads etc).

Cheers

Mike Thomas