

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>

Tue, 13 Jan 2004 17:37:09 +1100
Claudio Natoli <claudio.natoli@memetrics.com>
Re: LWLock/ShmemIndex startup question 
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

Tue, 13 Jan 2004 09:54:23 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: LWLock/ShmemIndex startup question 
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, Pennsylvania 19073

Thu, 22 Jan 2004 23:56:40 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: LWLock/ShmemIndex startup question