Content-Type: text/plain;
  charset="iso-8859-1"
From: Philip Yarra <philip@utiba.com>
Organization: Utiba
To: Lee Kindness <lkindness@csl.co.uk>
Subject: ECPG thread success (kind of) on Linux
Date: Fri, 27 Jun 2003 10:45:46 +1000
User-Agent: KMail/1.4.3
Cc: pgsql-interfaces@postgresql.org, pgsql-hackers@postgresql.org
References: <200306241825.32527.philip@utiba.com>
	<16121.27884.841077.431930@kelvin.csl.co.uk>
	<200306261119.09242.philip@utiba.com>
In-Reply-To: <200306261119.09242.philip@utiba.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200306271045.46789.philip@utiba.com>

On Thu, 26 Jun 2003 11:19 am, Philip Yarra wrote:

> there appears to still be a problem
> occurring at "EXEC SQL DISCONNECT con_name". I'll look into it tonight if=
 I
> can.

I did some more poking around last night, and believe I have found the issu=
e:=20
RedHat Linux 7.3 (the only distro I have access to currently) ships with a=
=20
fairly challenged pthreads inplementation. The default mutex type (which yo=
u=20
get from PTHREAD_MUTEX_INITIALIZER) is, according the the man page,=20
PTHREAD_MUTEX_FAST_NP which is not a recursive mutex. If a thread owns a=20
mutex and attempts to lock the mutex again, it will hang.=20

By replacing PTHREAD_MUTEX_INITIALIZER with PTHREAD_MUTEX_RECURSIVE_NP for =
the=20
two mutexes that are used recursively (debug_mutex and connections_mutex) I=
=20
got my sample app to work flawlessly on Linux RedHat 7.3

Sadly, the _NP suffix is used to indicate non-portable, so of course my=20
FreeBSD box steadfastly refused to compile it. Darn.

The correct way to do this appears to be:

pthread_mutexattr_t *mattr;
pthread_mutexattr_settype(mattr, PTHREAD_MUTEX_RECURSIVE);

(will verify this against FreeBSD when I get home, and Tru64 man page=20
indicates support for this too, so I'll test that later). It won't work on=
=20=20
RedHat Linux 7.3... I guess something like:

#ifdef DODGY_PTHREADS
#define PTHREAD_MUTEX_RECURSIVE =3D PTHREAD_MUTEX_RECURSIVE_NP
#endif

might do it... if we could detect the problem during configure. How is this=
=20
sort of detection handled in other cases (such as long long, etc)?

The other solution I can think of is to eradicate the two recursive locks I=
=20
found.

One is simple: ECPGlog calls ECPGdebug, which share debug_mutex - it ought =
to=20
be okay to use different mutexes for each of these functions (there's a ris=
k=20
someone might call ECPGdebug while someone else is running through ECPGlog,=
=20
but I think it is less likely, since it is a debug mechanism.)

The second recursive lock I found is ECPGdisconnect calling=20
ECPGget_connection, both of which share a mutex. Would it be okay if we did=
=20
the following:

ECPGdisconnect() still locks connections_mutex, but calls=20
ECPGget_connection_nr() instead of ECPGget_connection()=20

ECPGget_connection() becomes a locking wrapper, which locks connections_mut=
ex=20
then calls ECPGget_connection_nr()

ECPGget_connection_nr() is a non-locking function which implements what=20
ECPGget_connection() currently does.

I'm not sure if this sort of thing is okay (and there may be other recursiv=
e=20
locking scenarios that I haven't exercised yet).

What approach should I take? I'm leaning towards eradicating recursive lock=
s,=20
unless someone has a good reason not to.

> All this does kinda raise the interesting question of why it worked at all
> on FreeBSD... probably different scheduling and blind luck, I suppose.

FreeBSD 4.8 must have PTHREAD_MUTEX_RECURSIVE as default mutex type. I'm a =
bit=20
concerned about FreeBSD 4.2 though - I noticed (before I blew it away in=20
favour of 4.8) that its pthreads implementation came from a package called=
=20
linuxthreads.tgz - it might have inherited the same problematic behaviour.=
=20
Could someone with access to or knowledge of FreeBSD 4.2 check what the=20
default mutex type is there?

Regards, Philip.

I can just see the ad for 7.3's pthreads impementation
"Fast mutexes: zero to deadlock in 6.9 milliseconds!"