Thread: LWLock/ShmemIndex startup question

LWLock/ShmemIndex startup question

From
Claudio Natoli
Date:
In CreateSharedMemoryAndSemaphores, there is the following comment, just
before CreateLWLocks():
/* * Now initialize LWLocks, which do shared memory allocation and are * needed for InitShmemIndex. */

Also, in InitShmemAllocation, there is:
/* ShmemIndex can't be set up yet (need LWLocks first) */

Are these comments still true? Specifically, is it necessary to call
CreateLWLocks before InitShmemIndex? I think it used to be, but then the
ShmemIndexLock got made into a separate spinlock in its own right.

It doesn't appear to be true, and I'd like to rearrange this section of the
code, as part of a possible solution to a Win32 shmem/semaphore bootstrap
problem (postgres semaphores under Win32 uses ShmemIndex which uses
spinlocks which use shared memory which use semaphores which ...).

If ok, I was specifically thinking of rolling the ShmemIndex initialization
into InitShmemAllocation, which I suspect used to do this anyway... any
complaints?

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>


Re: LWLock/ShmemIndex startup question

From
Tom Lane
Date:
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Are these comments still true? Specifically, is it necessary to call
> CreateLWLocks before InitShmemIndex? I think it used to be, but then the
> ShmemIndexLock got made into a separate spinlock in its own right.

I think the only dependency was that ShmemIndexLock was an LWLock.

> It doesn't appear to be true, and I'd like to rearrange this section of the
> code,

You have broken stuff before by rearranging the sequence of
operations... what exactly have you got in mind here?

> ... a possible solution to a Win32 shmem/semaphore bootstrap
> problem (postgres semaphores under Win32 uses ShmemIndex which uses
> spinlocks which use shared memory which use semaphores which ...).

The correct solution to that seems to lie elsewhere, ie, not use
semaphores for spinlocks.
        regards, tom lane


Re: LWLock/ShmemIndex startup question

From
Claudio Natoli
Date:

> You have broken stuff before by rearranging the sequence of
operations... 

Ah, yeah, well, FWIW, if that is the only thing that gets broken in the
process of making this port, I'll be more than satisfied. Will that be held
against me forever?


> what exactly have you got in mind here?

Moving InitShmemIndex into InitShmemAllocation. 

I'd like to make this the first call, inside the context of ShmemBootstrap =
true, and insert logic to avoid SpinLock acquisition/release inside
ShmemAlloc/ShmemInitStruct (when ShmemBootstrap = true). Not pretty, but
I'll trade off the removal of other ugliness (like the
ShmemLock/ShmemIndexLock spinlock memory allocation, which could then just
use ShmemAlloc).


> > ... a possible solution to a Win32 shmem/semaphore bootstrap
> > problem (postgres semaphores under Win32 uses ShmemIndex which uses
> > spinlocks which use shared memory which use semaphores which ...).

> The correct solution to that seems to lie elsewhere, ie, not use
semaphores for spinlocks.

Just working with what we've already got. There seems to be very usable code
in src/backend/port/win32/sema.c, which gets invoked as Win32 does not have
spin-locks, but unfortunately relies on ShmemInitStruct.

If you've got a shorter path in mind, I'm all ears.

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>


Re: LWLock/ShmemIndex startup question

From
Tom Lane
Date:
Claudio Natoli <claudio.natoli@memetrics.com> writes:
>> The correct solution to that seems to lie elsewhere, ie, not use
>> semaphores for spinlocks.

> Just working with what we've already got. There seems to be very usable code
> in src/backend/port/win32/sema.c, which gets invoked as Win32 does not have
> spin-locks, but unfortunately relies on ShmemInitStruct.

Win32 certainly has spinlocks; it does not run on any hardware for which
we don't have spinlock assembler.  For that matter, doesn't it have
POSIX-compatible semaphores?  I'm not sure there's any need for
src/backend/port/win32/sema.c at all.
        regards, tom lane


Re: LWLock/ShmemIndex startup question

From
Claudio Natoli
Date:

Tom Lane writes:
> > Just working with what we've already got. There seems to be very 
> > usable code in src/backend/port/win32/sema.c, which gets invoked 
> > as Win32 does not have spin-locks, but unfortunately relies on 
> > ShmemInitStruct.
>
> Win32 certainly has spinlocks; it does not run on any hardware for which
> we don't have spinlock assembler.  For that matter, doesn't it have
> POSIX-compatible semaphores?  I'm not sure there's any need for
> src/backend/port/win32/sema.c at all.

["as Win32 does not have" should have been read as "as Postgres Win32 does
not have"]

I'll have a look at how we could fit in spinlock code for Win32, or at
least, using the Win32 semaphores. (Do you have any idea on the historical
context of this code? I wondered as to, if we have no win32 port, why there
would be a seemingly good-to-go sema replacement?)

No chance on getting the Shmem bootrap rearrangement past you, as described
in my earlier mail? IMNSHO, it is not entirely without merit.

Cheers,
Claudio



--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>


Re: LWLock/ShmemIndex startup question

From
Tom Lane
Date:
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Tom Lane writes:
>> I'm not sure there's any need for
>> src/backend/port/win32/sema.c at all.

> (Do you have any idea on the historical
> context of this code? I wondered as to, if we have no win32 port, why there
> would be a seemingly good-to-go sema replacement?)

[cvs is your friend...]  It appears to have been added as part of the
MinGW porting work last May.  I don't have much faith in it; as far as
I heard the MinGW port never got further than making the client-side
code work, and so this file has no real-world testing.

> No chance on getting the Shmem bootrap rearrangement past you, as described
> in my earlier mail?

I didn't say no chance, I was just questioning the reason.  We don't
need a slavish implementation of SysV semaphores.  What we need is
something implementing the API defined by src/include/storage/pg_sema.h
for which we presently have two implementations:src/backend/port/posix_sema.csrc/backend/port/sysv_sema.c
(actually three implementations if you count named and unnamed POSIX
semaphores as different, which you very well could).  I'd be inclined
to think that something using Windows-native semaphore primitives to
implement this API is the way to go.
        regards, tom lane


Re: LWLock/ShmemIndex startup question

From
Claudio Natoli
Date:

Tom Lane writes:
> [cvs is your friend...]  It appears to have been added as part of the
> MinGW porting work last May.  I don't have much faith in it; as far as
> I heard the MinGW port never got further than making the client-side
> code work, and so this file has no real-world testing.

FWIW, I've done a code walk-through, and it looks ok (lack of real-world
testing notwithstanding), and actually does use the Win32 sema set. The only
real problem is that it calls ShmemInitStruct in semget, which ultimately
gets us into bootstrap hell (without native spinlocks, at least).

Also, as far as using it in the "hardware independent" version of spin-locks
go, it makes kernel calls, which, as spin.c comments: "is too slow to be
very useful".


> > No chance on getting the Shmem bootrap rearrangement past you, as 
> > described in my earlier mail?
>
> I didn't say no chance, I was just questioning the reason.  

This was my only reasoning (with the small benefit that it rids us of the
ShmemLock/ShmemIndexLock creation ugliness, for equivalent ShmemBootstrap
ugliness).

Ok, I think having a native win32 spin-lock implementation (say, based on
InterlockedCompareExchange?) is the minimal impact answer. I'll work on
producing that.

Cheers,
Claudio


--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>


Re: LWLock/ShmemIndex startup question

From
Claudio Natoli
Date:
> Ok, I think having a native win32 spin-lock implementation 
> (say, based on InterlockedCompareExchange?) is the minimal 
> impact answer. I'll work on producing that.

Or, maybe we'll just use the tas() implementation that already exists for
__i386__/__x86_64__ in s_lock.h. How did I miss that?

Move along. Nothing to see here.

Cheers,
Claudio

--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>


Re: LWLock/ShmemIndex startup question

From
Tom Lane
Date:
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> FWIW, I've done a code walk-through, and it looks ok (lack of real-world
> testing notwithstanding), and actually does use the Win32 sema set. The only
> real problem is that it calls ShmemInitStruct in semget, which ultimately
> gets us into bootstrap hell (without native spinlocks, at least).

Right.  The advantage of the pg_sema.h API is that you don't need any
shared control data.  Take a close look at the way posix_sema works:
the management information needed to release the semas at shutdown is
private to the postmaster.  What is in shared memory need only be a
reference or token (whatever you have to hand to the lock/unlock calls).
Also, allocation of the shmem space is not the responsibility of the
startup routine.  So all these issues go away as long as you're not
trying to emulate the SysV interface.
        regards, tom lane


Re: LWLock/ShmemIndex startup question

From
Tom Lane
Date:
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Or, maybe we'll just use the tas() implementation that already exists for
> __i386__/__x86_64__ in s_lock.h. How did I miss that?
> Move along. Nothing to see here.

Actually, I was expecting you to complain that the s_lock.h coding is
gcc-specific.  Which compilers do we need to support on Windows?

We might have to fall back to something comparable to the CVS-tip s_lock
support for hppa: inline assembler in s_lock.h for gcc, and a separate
assembly source file for use with vendor compiler(s).
        regards, tom lane


Re: LWLock/ShmemIndex startup question

From
Manfred Spraul
Date:
Tom Lane wrote:

>Claudio Natoli <claudio.natoli@memetrics.com> writes:
>  
>
>>Or, maybe we'll just use the tas() implementation that already exists for
>>__i386__/__x86_64__ in s_lock.h. How did I miss that?
>>Move along. Nothing to see here.
>>    
>>
>
>Actually, I was expecting you to complain that the s_lock.h coding is
>gcc-specific.  Which compilers do we need to support on Windows?
>  
>
I think intel's compiler supports the gcc syntax. At least the Linux 
version can compile the Linux kernel.
MSVC has it's own syntax that is very primitive, and AFAIK not supported 
by the 64-bit windows versions. The AMD64 version definitively doesn't 
support inline assembly at all.

What are the chances for Win64 support? sizeof(unsigned long) remains 4, 
sizeof(void*) is 8.

--   Manfred





Re: LWLock/ShmemIndex startup question

From
"Andrew Dunstan"
Date:
Tom Lane said:
>
> Actually, I was expecting you to complain that the s_lock.h coding is
> gcc-specific.  Which compilers do we need to support on Windows?
>

AFAIK the only target build environment for Windows right now is MinGW/gcc

If anyone knows how to get the M$ compilers to work nicely with our build
system that might be interesting, but probably at a later stage.

cheers

andrew




Re: LWLock/ShmemIndex startup question

From
Tom Lane
Date:
Manfred Spraul <manfred@colorfullife.com> writes:
> What are the chances for Win64 support? sizeof(unsigned long) remains 4, 
> sizeof(void*) is 8.

If you can tell me what type Datum should be (unsigned long long
maybe?), we could probably handle that.  It was a pretty brain-dead
combination of choices on Microsoft's part though ... offhand I can
think of no other platform where pointer and long are not the same
size.  There are probably a few other places besides the Datum typedef
that will need adjustment for this, but I can't think of any showstoppers.
        regards, tom lane


Re: LWLock/ShmemIndex startup question

From
Manfred Spraul
Date:
Tom Lane wrote:

>Manfred Spraul <manfred@colorfullife.com> writes:
>  
>
>>What are the chances for Win64 support? sizeof(unsigned long) remains 4, 
>>sizeof(void*) is 8.
>>    
>>
>
>If you can tell me what type Datum should be (unsigned long long
>maybe?), we could probably handle that.
>
Probably uintptr_t: That's the official C99 integer type for storing 
pointers. I'm not sure if it's guaranteed to be wide enough for 
ULONG_MAX (or only UINT_MAX).

--   Manfred



Re: LWLock/ShmemIndex startup question

From
Claudio Natoli
Date:
 
> Tom Lane said:
> >
> > Actually, I was expecting you to complain that the s_lock.h coding is
> > gcc-specific.  Which compilers do we need to support on Windows?
> >
> 
> AFAIK the only target build environment for Windows right now is
> MinGW/gcc

Yes, I'm working with MingW.


> If anyone knows how to get the M$ compilers to work nicely with our
> build system that might be interesting, but probably at a later stage.

Agreed. Although there's marginal worth in this, as anyone interested enough
to build Postgres from sources for Windows ought to have no problem
downloading and doing so from MingW. But if somone gets the itch...

Cheers,
Claudio
--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>


Re: LWLock/ShmemIndex startup question

From
Bruce Momjian
Date:
Andrew Dunstan wrote:
> Tom Lane said:
> >
> > Actually, I was expecting you to complain that the s_lock.h coding is
> > gcc-specific.  Which compilers do we need to support on Windows?
> >
> 
> AFAIK the only target build environment for Windows right now is MinGW/gcc
> 
> If anyone knows how to get the M$ compilers to work nicely with our build
> system that might be interesting, but probably at a later stage.

MS C compiler usage would require gmake and a whole host of other stuff
that doesn't seem worth doing.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: LWLock/ShmemIndex startup question

From
Bruce Momjian
Date:
Tom Lane wrote:
> Claudio Natoli <claudio.natoli@memetrics.com> writes:
> > Tom Lane writes:
> >> I'm not sure there's any need for
> >> src/backend/port/win32/sema.c at all.
> 
> > (Do you have any idea on the historical
> > context of this code? I wondered as to, if we have no win32 port, why there
> > would be a seemingly good-to-go sema replacement?)
> 
> [cvs is your friend...]  It appears to have been added as part of the
> MinGW porting work last May.  I don't have much faith in it; as far as
> I heard the MinGW port never got further than making the client-side
> code work, and so this file has no real-world testing.

Right, that is from PeerDirect's Win32 port, with a little cleanup.  It
should work fine, or we can wack it around.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: LWLock/ShmemIndex startup question

From
Bruce Momjian
Date:
Tom Lane wrote:
> Claudio Natoli <claudio.natoli@memetrics.com> writes:
> > Or, maybe we'll just use the tas() implementation that already exists for
> > __i386__/__x86_64__ in s_lock.h. How did I miss that?
> > Move along. Nothing to see here.
> 
> Actually, I was expecting you to complain that the s_lock.h coding is
> gcc-specific.  Which compilers do we need to support on Windows?
> 
> We might have to fall back to something comparable to the CVS-tip s_lock
> support for hppa: inline assembler in s_lock.h for gcc, and a separate
> assembly source file for use with vendor compiler(s).

MinGW only uses gcc so we are OK there.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: LWLock/ShmemIndex startup question

From
Bruce Momjian
Date:
Claudio Natoli wrote:
> 
> 
> Tom Lane writes:
> > [cvs is your friend...]  It appears to have been added as part of the
> > MinGW porting work last May.  I don't have much faith in it; as far as
> > I heard the MinGW port never got further than making the client-side
> > code work, and so this file has no real-world testing.
> 
> FWIW, I've done a code walk-through, and it looks ok (lack of real-world
> testing notwithstanding), and actually does use the Win32 sema set. The only
> real problem is that it calls ShmemInitStruct in semget, which ultimately
> gets us into bootstrap hell (without native spinlocks, at least).
> 
> Also, as far as using it in the "hardware independent" version of spin-locks
> go, it makes kernel calls, which, as spin.c comments: "is too slow to be
> very useful".

Yep, native gcc TAS assembler should work fine on MinGW with gcc.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: LWLock/ShmemIndex startup question

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Andrew Dunstan wrote:
>> AFAIK the only target build environment for Windows right now is MinGW/gcc
>> 
>> If anyone knows how to get the M$ compilers to work nicely with our build
>> system that might be interesting, but probably at a later stage.

> MS C compiler usage would require gmake and a whole host of other stuff
> that doesn't seem worth doing.

Um, good point.  Porting our Makefiles to anything but gmake seems
completely out of the question.  So unless someone has a Windows build
environment that has gmake but not gcc, this is moot.
        regards, tom lane


Re: LWLock/ShmemIndex startup question

From
Andrew Dunstan
Date:

Bruce Momjian wrote:

>Andrew Dunstan wrote:
>  
>
>>Tom Lane said:
>>    
>>
>>>Actually, I was expecting you to complain that the s_lock.h coding is
>>>gcc-specific.  Which compilers do we need to support on Windows?
>>>
>>>      
>>>
>>AFAIK the only target build environment for Windows right now is MinGW/gcc
>>
>>If anyone knows how to get the M$ compilers to work nicely with our build
>>system that might be interesting, but probably at a later stage.
>>    
>>
>
>MS C compiler usage would require gmake and a whole host of other stuff
>that doesn't seem worth doing.
>  
>

That's why I phrased the suggestion rather tentatively :-)

cheers

andrew



Re: LWLock/ShmemIndex startup question

From
Robert Treat
Date:
On Fri, 2004-01-23 at 00:21, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Andrew Dunstan wrote:
> >> AFAIK the only target build environment for Windows right now is MinGW/gcc
> >> 
> >> If anyone knows how to get the M$ compilers to work nicely with our build
> >> system that might be interesting, but probably at a later stage.
> 
> > MS C compiler usage would require gmake and a whole host of other stuff
> > that doesn't seem worth doing.
> 
> Um, good point.  Porting our Makefiles to anything but gmake seems
> completely out of the question.  So unless someone has a Windows build
> environment that has gmake but not gcc, this is moot.
> 

Tom, check out
http://archives.postgresql.org/pgsql-ports/2004-01/msg00017.php

Looking at the interix website, they seem to have gmake but no gcc,
which seems to fit into your scenario above. Incedentally they do 
distribute a compiled PostgreSQL with their packages, though it's based
on 7.2 according to the author.  

Robert Treat 
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL