[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Threads vs. OpenMP in PSPP.
From: |
Ben Pfaff |
Subject: |
Re: Threads vs. OpenMP in PSPP. |
Date: |
Mon, 02 Apr 2007 22:22:24 -0700 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
John Darrington <address@hidden> writes:
> Regardless of whether OpenMP or something else is used, any use of
> underlying libraries have to be thread safe ... and our libpspp and data
> libraries are currently not. They could be made safe with a few
> synchronisations --- but the API you use for synchronisation has to be
> available on all platforms...
I don't think that src/libpspp or src/data use much in the way of
static data, at least not anymore, so they would be sequentially
thread-safe or at least close to it.
It might be easier to adapt PSPP to a threaded design after my
branch is merged: there's a certain amount of copy-on-write and
reference counting functionality in this branch already, and it
is possible that it could be made thread-safe pretty simply.
I'll have to look it over.
Gnulib also contains a number of functions that aren't
thread-safe, some of which we are using now, I think. All of it
will need review.
> Also, for psppire, we have access to the glib thread library, which is
> designed to be portable. This may be a better choice for splitting the
> gui thread from the work thread. I don't know if g_threads play well
> with OpenMP. It may be possible to use the minimal threading API in
> OpenMP to support splitting the gui thread.
>
> The GThread stuff in GLib is just a wrapper around whatever threading
> library is supported on the platform concerned. In the case of
> GNU/Linux, this is PThreads.
Gnulib contains some support for cross-platform synchronization
in the "lock" module. It doesn't, unfortunately, have
cross-platform functionality for creating threads or destroying
them, joining them, etc.
A quick web search reveals that there is a Pthreads emulation
library for Win32, called Pthreads-win32:
http://sources.redhat.com/pthreads-win32/
It might be most straightforward to program against Pthreads,
which is supported by all modern Unix flavo(u)rs, and encourage
Windows users to use Pthreads-win32. As long as we could also
support compiling without thread support, I bet this would be
just fine.
I haven't read the OpenMP spec, so I can't say much about it
knowledgeably yet. I'll try to skim through it soon.
--
Ben Pfaff
http://benpfaff.org