Hello all,

it's very interesting to see the discussion of "threads" again.

I've portet PostgreSQL to a "thread-per-connection" model based on
pthreads
and it is functional. Most of the work was finding all the static
globals in the sourcefiles
and swapping them between threads and freeing memory if a thread
terminates.
(PostgreSQL isn't written very clean in the aspects of memory
handling).

My version of the thread-based PostgreSQL is not very efficient at the
moment because
I haven't done any optimisation of the code to better support threads
and I'm using just a
simple semaphore to control switching of data but this could be a
starting point for
others who want to see this code. If this direction will be taken
seriously I'm very willing
to help.

If someone is interested in the code I can send a zip file to everyone
who wants.

Ulrich
----------------------------------
  This e-mail is virus scanned
  Diese e-mail ist virusgeprueft


Mon, 06 Jan 2003 12:22:57 +0100
"Ulrich Neumann" <U_Neumann@gne.de>
Re: Threads
On 6 Jan 2003 at 12:22, Ulrich Neumann wrote:

> Hello all,
> If someone is interested in the code I can send a zip file to everyone
> who wants.

I suggest you preserver your work. The reason I suggested thread are mainly two 
folds.

1) Get I/O time used fuitfully
2) Use multiple CPU better.

It will not require as much code cleaning as your efforts might had. However 
your work will be very useful if somebody decides to use thread in any fashion 
in core postgresql.

I was hoping for bit more optimistic response given that what I suggested was 
totally optional at any point of time but very important from performance 
point. Besides the change would have been gradual as required..

Anyway..

Bye
 Shridhar

--
Robot, n.:	University administrator.


Mon, 06 Jan 2003 17:06:19 +0530
"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
Re: Threads
On Mon, 2003-01-06 at 05:36, Shridhar Daithankar wrote:
> On 6 Jan 2003 at 12:22, Ulrich Neumann wrote:
> 
> > Hello all,
> > If someone is interested in the code I can send a zip file to everyone
> > who wants.
> 
> I suggest you preserver your work. The reason I suggested thread are mainly two 
> folds.
> 
> 1) Get I/O time used fuitfully


AIO may address this without the need for integrated threading. 
Arguably, from the long thread that last appeared on the topic of AIO,
some hold that AIO doesn't even offer anything beyond the current
implementation.  As such, it's highly doubtful that integrated threading
is going to offer anything beyond what a sound AIO implementation can
achieve.


> 2) Use multiple CPU better.
> 


Multiple processes tend to universally support multiple CPUs better than
does threading.  On some platforms, the level of threading support is
currently only user mode implementations which means no additional CPU
use.  Furthermore, some platforms where user-mode threads are defacto,
they don't even allow for scheduling bias resulting is less work being
accomplished within the same time interval (work slice must be divided
between n-threads within the process, all of which run on a single CPU).


> It will not require as much code cleaning as your efforts might had. However 
> your work will be very useful if somebody decides to use thread in any fashion 
> in core postgresql.
> 
> I was hoping for bit more optimistic response given that what I suggested was 
> totally optional at any point of time but very important from performance 
> point. Besides the change would have been gradual as required..
> 


Speaking for my self, I probably would of been more excited if the
offered framework had addressed several issues.  The short list is:

o Code needs to be more robust.  It shouldn't be calling exit directly
as, I believe, it should be allowing for PostgreSQL to clean up some. 
Correct me as needed.  I would of also expected the code of adopted
PostgreSQL's semantics and mechanisms as needed (error reporting, etc). 
I do understand it was an initial attempt to simply get something in
front of some eyes and have something to talk about.  Just the same, I
was expecting something that we could actually pull the trigger with.

o Code isn't very portable.  Looked fairly okay for pthread platforms,
however, there is new emphasis on the Win32 platform.  I think it would
be a mistake to introduce something as significant as threading without
addressing Win32 from the get-go.

o I would desire a more highly abstracted/portable interface which
allows for different threading and synchronization primitives to be
used.  Current implementation is tightly coupled to pthreads. 
Furthermore, on platforms such as Solaris, I would hope it would easily
allow for plugging in its native threading primitives which are touted
to be much more efficient than pthreads on said platform.

o Code is not commented.  I would hope that adding new code for
something as important as threading would be commented.

o Code is fairly trivial and does not address other primitives
(semaphores, mutexs, conditions, TSS, etc) portably which would be
required for anything but the most trivial of threaded work.  This is
especially true in such an application where data IS the application. 
As such, you must reasonably assume that threads need some form of
portable serialization primitives, not to mention mechanisms for
non-trivial communication.

o Does not address issues such as thread signaling or status reporting.

o Pool interface is rather simplistic.  Does not currently support
concepts such as wake pool, stop pool, pool status, assigning a pool to
work, etc.  In fact, it's not altogether obvious what the capabilities
intent is of the current pool implementation.

o Doesn't seem to address any form of thread communication facilities
(mailboxes, queues, etc).


There are probably other things that I can find if I spend more than
just a couple of minutes looking at the code.  Honestly, I love threads
but I can see that the current code offering is not much more than a
token in its current form.  No offense meant.

After it's all said and done, I'd have to see a lot more meat before I'd
be convinced that threading is ready for PostgreSQL; from both a social
and technological perspective.


Regards,

-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting


06 Jan 2003 06:48:23 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: Threads
On 6 Jan 2003 at 6:48, Greg Copeland wrote:
> > 1) Get I/O time used fuitfully
> AIO may address this without the need for integrated threading. 
> Arguably, from the long thread that last appeared on the topic of AIO,
> some hold that AIO doesn't even offer anything beyond the current
> implementation.  As such, it's highly doubtful that integrated threading
> is going to offer anything beyond what a sound AIO implementation can
> achieve.

Either way, a complete aio or threading implementation is not available on 
major platforms that postgresql runs. Linux definitely does not have one, last 
I checked.

If postgresql is not using aio or threading, we should start using one of them, 
is what I feel. What do you say?

> > 2) Use multiple CPU better.
> Multiple processes tend to universally support multiple CPUs better than
> does threading.  On some platforms, the level of threading support is
> currently only user mode implementations which means no additional CPU
> use.  Furthermore, some platforms where user-mode threads are defacto,
> they don't even allow for scheduling bias resulting is less work being
> accomplished within the same time interval (work slice must be divided
> between n-threads within the process, all of which run on a single CPU).

The frame-work I have posted, threading is optional at build and should be a 
configuration option if it gets integrated. So for the platforms that can not 
spread threads across multiple CPUs, it can simply be turned off..

> Speaking for my self, I probably would of been more excited if the
> offered framework had addressed several issues.  The short list is:
> 
> o Code needs to be more robust.  It shouldn't be calling exit directly
> as, I believe, it should be allowing for PostgreSQL to clean up some. 
> Correct me as needed.  I would of also expected the code of adopted
> PostgreSQL's semantics and mechanisms as needed (error reporting, etc). 
> I do understand it was an initial attempt to simply get something in
> front of some eyes and have something to talk about.  Just the same, I
> was expecting something that we could actually pull the trigger with.

That could be done.

> 
> o Code isn't very portable.  Looked fairly okay for pthread platforms,
> however, there is new emphasis on the Win32 platform.  I think it would
> be a mistake to introduce something as significant as threading without
> addressing Win32 from the get-go.

If you search for "pthread" in thread.c, there are not many instances. Same 
goes for thread.h. From what I understand windows threading, it would be less 
than 10 minutes job to #ifdef the pthread related part on either file.

It is just that I have not played with windows threading and nor I am inclined 
to...;-)

> 
> o I would desire a more highly abstracted/portable interface which
> allows for different threading and synchronization primitives to be
> used.  Current implementation is tightly coupled to pthreads. 
> Furthermore, on platforms such as Solaris, I would hope it would easily
> allow for plugging in its native threading primitives which are touted
> to be much more efficient than pthreads on said platform.

Same as above. If there can be two cases separated with #ifdef, there can be 
more.. But what is important is to have a thread that can be woken up as and 
when required with any function desired. That is the basic idea.

> o Code is not commented.  I would hope that adding new code for
> something as important as threading would be commented.

Agreed. 
 
> o Code is fairly trivial and does not address other primitives
> (semaphores, mutexs, conditions, TSS, etc) portably which would be
> required for anything but the most trivial of threaded work.  This is
> especially true in such an application where data IS the application. 
> As such, you must reasonably assume that threads need some form of
> portable serialization primitives, not to mention mechanisms for
> non-trivial communication.

I don't get this. Probably I should post a working example. It is not threads 
responsibility to make a function thread safe which is changed on the fly. The 
function has to make sure that it is thread safe. That is altogether different 
effort..
 
> o Does not address issues such as thread signaling or status reporting.

 From what I learnt from pthreads on linux, I would not mix threads and signals. 
One can easily add code in runner function that disables any signals for thread 
while the thread starts running. This would leave original signal handling 
mechanism in place.

As far as status reporting is concerned, the thread sould be initiated while 
back-end starts and terminated with backend termination. What is about status 
reporting?
 
> o Pool interface is rather simplistic.  Does not currently support
> concepts such as wake pool, stop pool, pool status, assigning a pool to
> work, etc.  In fact, it's not altogether obvious what the capabilities
> intent is of the current pool implementation.

Could you please elaborate? I am using same interface in c++ for a server 
application and never faced a problem like that..;-)

 
> o Doesn't seem to address any form of thread communication facilities
> (mailboxes, queues, etc).

Not part of this abstraction of threading mechanism. Intentionally left out to 
keep things clean.

> There are probably other things that I can find if I spend more than
> just a couple of minutes looking at the code.  Honestly, I love threads
> but I can see that the current code offering is not much more than a
> token in its current form.  No offense meant.

None taken. Point is it is useful and that is enough for me. If you could 
elaborate examples for any problems you see, I can probably modify it. (Code 
documentation is what I will do now)

> After it's all said and done, I'd have to see a lot more meat before I'd
> be convinced that threading is ready for PostgreSQL; from both a social
> and technological perspective.

Tell me about it..

 
Bye
 Shridhar

--
What's this script do?    unzip ; touch ; finger ; mount ; gasp ; yes ; umount 
; sleepHint for the answer: not everything is computer-oriented. Sometimes 
you'rein a sleeping bag, camping out.(Contributed by Frans van der Zande.)


Tue, 07 Jan 2003 13:30:05 +0530
"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
Re: Threads
On Tue, 2003-01-07 at 02:00, Shridhar Daithankar wrote:
> On 6 Jan 2003 at 6:48, Greg Copeland wrote:
> > > 1) Get I/O time used fuitfully
> > AIO may address this without the need for integrated threading. 
> > Arguably, from the long thread that last appeared on the topic of AIO,
> > some hold that AIO doesn't even offer anything beyond the current
> > implementation.  As such, it's highly doubtful that integrated threading
> > is going to offer anything beyond what a sound AIO implementation can
> > achieve.
> 
> Either way, a complete aio or threading implementation is not available on 
> major platforms that postgresql runs. Linux definitely does not have one, last 
> I checked.
> 

There are two or three significant AIO implementation efforts currently
underway for Linux.  One such implementation is available from the Red
Hat Server Edition (IIRC) and has been available for some time now.  I
believe Oracle is using it.  SGI also has an effort and I forget where
the other one comes from.  Nonetheless, I believe it's going to be a
hard fought battle to get AIO implemented simply because I don't think
anyone, yet, can truly argue a case on the gain vs effort.

> If postgresql is not using aio or threading, we should start using one of them, 
> is what I feel. What do you say?
> 

I did originally say that I'd like to see an AIO implementation.  Then
again, I don't current have a position to stand other than simply saying
it *might* perform better.  ;)  Not exactly a position that's going to
win the masses over.  

> > was expecting something that we could actually pull the trigger with.
> 
> That could be done.
> 

I'm sure it can, but that's probably the easiest item to address.

> > 
> > o Code isn't very portable.  Looked fairly okay for pthread platforms,
> > however, there is new emphasis on the Win32 platform.  I think it would
> > be a mistake to introduce something as significant as threading without
> > addressing Win32 from the get-go.
> 
> If you search for "pthread" in thread.c, there are not many instances. Same 
> goes for thread.h. From what I understand windows threading, it would be less 
> than 10 minutes job to #ifdef the pthread related part on either file.
> 
> It is just that I have not played with windows threading and nor I am inclined 
> to...;-)
> 

Well, the method above is going to create a semi-ugly mess.  I've
written thread abstraction layers which cover OS/2, NT, and pthreads. 
Each have subtle distinction.  What really needs to be done is the
creation of another abstraction layer which your current code would sit
on top of.  That way, everything contained within is clear and easy to
read.  The big bonus is that as additional threading implementations
need to be added, only the "low-level" abstraction stuff needs to
modified.  Done properly, each thread implementation would be it's own
module requiring little #if clutter.

As you can see, that's a fair amount of work and far from where the code
currently is.

> > 
> > o I would desire a more highly abstracted/portable interface which
> > allows for different threading and synchronization primitives to be
> > used.  Current implementation is tightly coupled to pthreads. 
> > Furthermore, on platforms such as Solaris, I would hope it would easily
> > allow for plugging in its native threading primitives which are touted
> > to be much more efficient than pthreads on said platform.
> 
> Same as above. If there can be two cases separated with #ifdef, there can be 
> more.. But what is important is to have a thread that can be woken up as and 
> when required with any function desired. That is the basic idea.
> 

Again, there's a lot of work in creating a well formed abstraction layer
for all of the mechanics that are required.  Furthermore, different
thread implementations have slightly different semantics which further
complicates things.  Worse, some types of primitives are simply not
available with some thread implementations.  That means those platforms
require it to be written from the primitives that are available on the
platform.  Yet more work.


> > o Code is fairly trivial and does not address other primitives
> > (semaphores, mutexs, conditions, TSS, etc) portably which would be
> > required for anything but the most trivial of threaded work.  This is
> > especially true in such an application where data IS the application. 
> > As such, you must reasonably assume that threads need some form of
> > portable serialization primitives, not to mention mechanisms for
> > non-trivial communication.
> 
> I don't get this. Probably I should post a working example. It is not threads 
> responsibility to make a function thread safe which is changed on the fly. The 
> function has to make sure that it is thread safe. That is altogether different 
> effort..


You're right, it's not the thread's responsibility, however, it is the
threading toolkit's.  In this case, you're offering to be the toolkit
which functions across two platforms, just for starters.  Reasonably,
you should expect a third to quickly follow.

>  
> > o Does not address issues such as thread signaling or status reporting.
> 
> >From what I learnt from pthreads on linux, I would not mix threads and signals. 
> One can easily add code in runner function that disables any signals for thread 
> while the thread starts running. This would leave original signal handling 
> mechanism in place.
> 
> As far as status reporting is concerned, the thread sould be initiated while 
> back-end starts and terminated with backend termination. What is about status 
> reporting?
>  
> > o Pool interface is rather simplistic.  Does not currently support
> > concepts such as wake pool, stop pool, pool status, assigning a pool to
> > work, etc.  In fact, it's not altogether obvious what the capabilities
> > intent is of the current pool implementation.
> 
> Could you please elaborate? I am using same interface in c++ for a server 
> application and never faced a problem like that..;-)
> 
>  
> > o Doesn't seem to address any form of thread communication facilities
> > (mailboxes, queues, etc).
> 
> Not part of this abstraction of threading mechanism. Intentionally left out to 
> keep things clean.
> 
> > There are probably other things that I can find if I spend more than
> > just a couple of minutes looking at the code.  Honestly, I love threads
> > but I can see that the current code offering is not much more than a
> > token in its current form.  No offense meant.
> 
> None taken. Point is it is useful and that is enough for me. If you could 
> elaborate examples for any problems you see, I can probably modify it. (Code 
> documentation is what I will do now)
> 
> > After it's all said and done, I'd have to see a lot more meat before I'd
> > be convinced that threading is ready for PostgreSQL; from both a social
> > and technological perspective.
> 
> Tell me about it..
> 

Long story short, if PostgreSQL is to use threads, it shouldn't be
handicapped by having a very limited subset of functionality.  With the
code that has been currently submitted, I don't believe you could even 
effectively implement a parallel sort.

To get an idea of the types of things that would be needed, check out
the ACE Toolkit.  There are a couple of other fairly popular toolkits as
well.  Nonetheless, it's a significant effort and the current code is a
long ways off from being usable.


-- 
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting


07 Jan 2003 10:06:12 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: Threads