Re: Threads - Mailing list pgsql-hackers

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