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.)