Re: [HACKERS] Threads vs Processes

From: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: [HACKERS] Threads vs Processes
Date: 2003-09-25 15:21:59
Message-ID: 3F730817.9020402@persistent.co.in
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-hackers-win32

Tom Lane wrote:

> Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
>
>>>How are you dealing with the issue of wanting some static variables to
>>>be per-thread and others not?
>
>
>>To be perfectly honest, I'm still trying to familiarize myself with the code
>>sufficiently well so that I can tell which variables need to be per-thread
>>and which are shared (and, in turn, which of these need to be protected from
>>concurrent access).
>
>
> Well, the first-order approximation would be to duplicate the current
> fork semantics: *all* static variables are per-thread, and should be
> copied from the parent thread at thread creation. If there is some
> reasonably non-invasive way to do that, we'd have a long leg up on the
> problem.

Hmm.. I was looking for some fast tutorials on thread local storage. I found
this one..
http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/thread_specific_data.htm

Basically, in a process we are free to declare as many globals as we can.
Converting them to thread local is not an easy job because each variable would
need it's own key and there is limit on how many keys can be allocated.

One thing that can be done is to arrange all globals/statics in a structure and
make that structure thread local. We need to change all invocations of any of
those variables to use a pointer. We just need only one global variable. And
some macro trickery possibly so that we can extend that structure easily and
automatically.

Upshot is duplicating environment is easy. We need to do a huge memcpy and any
specific depp copy of strings on thread creation. Besides even in process model,
this kind of initialization will allow to put all variables on heap instead of
stack. But then we need to add initialization code explicitly.

Something like int a=10; can not be added just like that.

If globals are less than 100 in numbers, I think it should be reasonably blind
job of converting them to a structure type stuff. Don't know really though. My
estimations are always 10% of what it takes..:-)

I hope I got it correct..

Shridhar

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2003-09-25 15:33:21 Re: pgsql-server/src/backend catalog/index.c comma ...
Previous Message Greg Stark 2003-09-25 15:18:51 Re: [pgsql-www] NuSphere and PostgreSQL for windows

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Manfred Spraul 2003-09-25 16:03:00 Re: [HACKERS] Threads vs Processes (was: NuSphere and PostgreSQL
Previous Message Tom Lane 2003-09-25 15:00:18 Re: Threads vs Processes (was: NuSphere and PostgreSQL for window s)