pspp-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]