Thread: LWLock/ShmemIndex startup question
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>
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
> 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>
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
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>
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
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>
> 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>
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
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
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
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
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
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
> 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>
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
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
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
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
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
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
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