Thread: ECPG - Specifying connections, TSD, sqlca.

ECPG - Specifying connections, TSD, sqlca.

From
Lee Kindness
Date:
Shridhar, Once the patches I've put forward are applied there's still
a further change I've got planned which will remove the mutex locking
in the common case - a NULL/DEFAULT connection parameter (I'll post a
patch soon). This leaves the threaded case with comparable performance
to the non-threaded case (both have a function call to get the
connection, plus a getspecific call in the threaded case). As such is
there much benefit in adding support for the connection being supplied
by a struct pointer? You'd also have to add in something like "EXEC
SQL GET DESCRIPTION xxx" to get the pointer too. How would it improve
things over how they are in the test_thread_implicit test program?

I still think it's worthwhile investigating the use of GCC's __thread
storage class specifier to remove the use of pthread_*specific in this
case. This would also be a help to the WIN32 port since this specifier
maps well to similar constructs in Microsoft's and Borland's compilers
(see "thread" item in the TODO at developer.postgresql.org).

And I still can't see how you'll bind sqlca to the connection object,
but best of luck!

Regards, Lee K.


Re: ECPG - Specifying connections, TSD, sqlca.

From
Bruce Momjian
Date:
Lee Kindness wrote:
> Shridhar, Once the patches I've put forward are applied there's still
> a further change I've got planned which will remove the mutex locking
> in the common case - a NULL/DEFAULT connection parameter (I'll post a
> patch soon). This leaves the threaded case with comparable performance
> to the non-threaded case (both have a function call to get the
> connection, plus a getspecific call in the threaded case). As such is
> there much benefit in adding support for the connection being supplied
> by a struct pointer? You'd also have to add in something like "EXEC
> SQL GET DESCRIPTION xxx" to get the pointer too. How would it improve
> things over how they are in the test_thread_implicit test program?
> 
> I still think it's worthwhile investigating the use of GCC's __thread
> storage class specifier to remove the use of pthread_*specific in this
> case. This would also be a help to the WIN32 port since this specifier
> maps well to similar constructs in Microsoft's and Borland's compilers
> (see "thread" item in the TODO at developer.postgresql.org).

I would like to avoid compiler-specific thread stuff unless tests can
show a performance benefit.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: ECPG - Specifying connections, TSD, sqlca.

From
Bruce Momjian
Date:
Lee Kindness wrote:
> From: "Bruce Momjian" <pgman@candle.pha.pa.us>
> > Lee Kindness wrote:
> > > I still think it's worthwhile investigating the use of GCC's __thread
> > > storage class specifier to remove the use of pthread_*specific in this
> > > case. This would also be a help to the WIN32 port since this specifier
> > > maps well to similar constructs in Microsoft's and Borland's compilers
> > > (see "thread" item in the TODO at developer.postgresql.org).
> > I would like to avoid compiler-specific thread stuff unless tests can
> > show a performance benefit.
> 
> I think concerns re performance are largely moot - with the thread specific
> data performance is much the same as without. However native compiler
> support for thread specific data is much more straightforward and
> understandable - you simply end up with a variable that can be used like any
> other except there is a copy of it for each thread.
> 
> To make ECPG thread-safe for WIN32 an additional set of thread calls will
> need to be added, and/or similar features to GCC's __thread storage
> specifier. If we end up adding these for WIN32 then it may as well be done
> for GCC too. I probably will experiment with it a bit (and get some real
> performance figure, rather than my hunch!)...
> 
> Perhaps a cleaner way is to use an existing thread package with encompasses
> the various platform APIs - i.e. APR or ACE, or... But that's a big
> discussion, and not one I'm keen to get into at the moment. A more
> appropriate time is perhaps once the WIN32 port is completed? It would also
> be straightforward to encompass this in an PostgreSQL specific API to wrap
> around the various calls we use and, if available, make these no-ops when a
> suitable storage class is supplied by the compiler? I'd be happy to write
> this API if others saw it as a way forward.
> 
> Perhaps someone would like to fwd this on to the hackers-win32 list (I'm not
> subscribed) to see what their view is on thread safety in the client
> libraries? And what approach they're planning?

I guess my point was that if there isn't a big performance win, why do
compiler specific and POSIX standard both in the same code.  The
compiler-specific might be clearer, but if we have to support non-gcc
too, which we do, adding a cleaner solution to one that is already
standard actually makes it look worse.

I don't think MinGW support thread-specific right now (no TLS support),
so we will need native Win32 in there anyway.  Adding a third seems like
more confusion.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: ECPG - Specifying connections, TSD, sqlca.

From
"Lee Kindness"
Date:
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
> Lee Kindness wrote:
> > I still think it's worthwhile investigating the use of GCC's __thread
> > storage class specifier to remove the use of pthread_*specific in this
> > case. This would also be a help to the WIN32 port since this specifier
> > maps well to similar constructs in Microsoft's and Borland's compilers
> > (see "thread" item in the TODO at developer.postgresql.org).
> I would like to avoid compiler-specific thread stuff unless tests can
> show a performance benefit.

I think concerns re performance are largely moot - with the thread specific
data performance is much the same as without. However native compiler
support for thread specific data is much more straightforward and
understandable - you simply end up with a variable that can be used like any
other except there is a copy of it for each thread.

To make ECPG thread-safe for WIN32 an additional set of thread calls will
need to be added, and/or similar features to GCC's __thread storage
specifier. If we end up adding these for WIN32 then it may as well be done
for GCC too. I probably will experiment with it a bit (and get some real
performance figure, rather than my hunch!)...

Perhaps a cleaner way is to use an existing thread package with encompasses
the various platform APIs - i.e. APR or ACE, or... But that's a big
discussion, and not one I'm keen to get into at the moment. A more
appropriate time is perhaps once the WIN32 port is completed? It would also
be straightforward to encompass this in an PostgreSQL specific API to wrap
around the various calls we use and, if available, make these no-ops when a
suitable storage class is supplied by the compiler? I'd be happy to write
this API if others saw it as a way forward.

Perhaps someone would like to fwd this on to the hackers-win32 list (I'm not
subscribed) to see what their view is on thread safety in the client
libraries? And what approach they're planning?

L.



Re: ECPG - Specifying connections, TSD, sqlca.

From
"Lee Kindness"
Date:
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
> Lee Kindness wrote:
> > Perhaps a cleaner way is to use an existing thread package with
encompasses
> > the various platform APIs - i.e. APR or ACE, or... But that's a big
> > discussion, and not one I'm keen to get into at the moment. A more
> > appropriate time is perhaps once the WIN32 port is completed? It would
also
> > be straightforward to encompass this in an PostgreSQL specific API to
wrap
> > around the various calls we use and, if available, make these no-ops
when a
> > suitable storage class is supplied by the compiler? I'd be happy to
write
> > this API if others saw it as a way forward.
> >
> I don't think MinGW support thread-specific right now (no TLS support),
> so we will need native Win32 in there anyway.  Adding a third seems like
> more confusion.

Ah, ok - i've not been following the win32 stuff so wasn't even sure on
compilers being used. I'd agree at this stage there's no point muddying the
waters even further!

I'll get back to you with the patch to move common-case connection retrieval
outwith the mutex once the earlier patches are applied.

Thanks, L.