Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-hackers-win32 by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group