agora inbox for [email protected]  

help / color / mirror / Atom feed

From: Shridhar Daithankar <[email protected]>
To: PostgreSQL Development <[email protected]>
Subject: Re:
Date: Tue, 22 Jul 2003 20:57:45 +0530
Message-ID: <3F1DA549.20040.49B0FD@localhost> (raw)
In-Reply-To: <[email protected]>

On 22 Jul 2003 at 16:55, Peter Eisentraut wrote:

> I've been thinking some about how exactly to provide the new option of
> thread-safe clients (libpq, ecpg).  Let me state the following goals:
> 
> a. Thread-safeness, where it makes a difference, is generally thought to
> be a performance hit, so the user needs to have a choice to use
> thread-safe libraries or not.

On linux and freeBSD, that is not an issue. I can attest that from my 
experiments with a webserver. Thread function calls often time less than or of 
the order of 1us even with CPU capped.

I would really like to know for what platforms, locking mutex while selecting 
from connection list or some such object, is going to be such a great 
performance hit.

Performance degradation in threaded programs comes from contentions. It goes 
for frequency of contention and number of threads fighting over it.

I doubt any threaded ecpg program would reach that level of contention anytime. 
If a lock canbe obtained/released in less than 10us and subsequent database 
query is going to take at least a ms, IMO that performance degradation is not 
worth that much trouble.

But that is for linux and freeBSD. What other platforms have serious thread 
issues?

> Clearly, a thread-safe ecpg library is always going to be significantly
> different from the "normal" one, with all the mutex things that get pulled
> in, so it seems reasonable to always offer a libecpg_r alongside the
> libecpg.

I would say, it should be thread-safe by default. No point polluting possible 
linkages.

I repeat what I have said earlier. If there are two libraries A using libecpg_r 
and B, using libecpg, then program linking against both of them is going to 
have tough time living with symbol conflicts. 

I suppose problem will be reproducible even under freeBSD if you try to create  
a postgresql function in C which uses threads. Link the library against libc_r 
and link postgresql against libc. It would run into problems.

I am just stating my experiences.I might have missed solution to this problem. 

But overall I like GNU libc approach of everything thread safe by default. If 
thread performance is an issue, then it should be improved. Not worked around 
with two libraries.

Just a thought..

Bye
 Shridhar

--
2180, U.S. History question:	What 20th Century U.S. President was almost impeached and what	office did he later hold?

view thread (45+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected]
  Subject: Re:
  In-Reply-To: <3F1DA549.20040.49B0FD@localhost>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox