database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Make the different Unix-y semaphore implementations ABI-compatible.

Browse Source 
Previously, the "sem" field of PGPROC varied in size depending on which
kernel semaphore API we were using.  That was okay as long as there was
only one likely choice per platform, but in the wake of commit ecb0d20a9,
that assumption seems rather shaky.  It doesn't seem out of the question
anymore that an extension compiled against one API choice might be loaded
into a postmaster built with another choice.  Moreover, this prevents any
possibility of selecting the semaphore API at postmaster startup, which
might be something we want to do in future.

Hence, change PGPROC.sem to be PGSemaphore (i.e. a pointer) for all Unix
semaphore APIs, and turn the pointed-to data into an opaque struct whose
contents are only known within the responsible modules.

For the SysV and unnamed-POSIX APIs, the pointed-to data has to be
allocated elsewhere in shared memory, which takes a little bit of
rejiggering of the InitShmemAllocation code sequence.  (I invented a
ShmemAllocUnlocked() function to make that a little cleaner than it used
to be.  That function is not meant for any uses other than the ones it
has now, but it beats having InitShmemAllocation() know explicitly about
allocation of space for semaphores and spinlocks.)  This change means an
extra indirection to access the semaphore data, but since we only touch
that when blocking or awakening a process, there shouldn't be any
meaningful performance penalty.  Moreover, at least for the unnamed-POSIX
case on Linux, the sem_t type is quite a bit wider than a pointer, so this
reduces sizeof(PGPROC) which seems like a good thing.

For the named-POSIX API, there's effectively no change: the PGPROC.sem
field was and still is a pointer to something returned by sem_open() in
the postmaster's memory space.  Document and check the pre-existing
limitation that this case can't work in EXEC_BACKEND mode.

It did not seem worth unifying the Windows semaphore ABI with the Unix
cases, since there's no likelihood of needing ABI compatibility much less
runtime switching across those cases.  However, we can simplify the Windows
code a bit if we define PGSemaphore as being directly a HANDLE, rather than
pointer to HANDLE, so let's do that while we're here.  (This also ends up
being no change in what's physically stored in PGPROC.sem.  We're just
moving the HANDLE fetch from callees to callers.)

It would take a bunch of additional code shuffling to get to the point of
actually choosing a semaphore API at postmaster start, but the effects
of that would now be localized in the port/XXX_sema.c files, so it seems
like fit material for a separate patch.  The need for it is unproven as
yet, anyhow, whereas the ABI risk to extensions seems real enough.

Discussion: https://postgr.es/m/4029.1481413370@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2016-12-12 13:32:10 -05:00
parent 06e184876b
commit be7b2848c6
14 changed files with 268 additions and 123 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
src/backend/port/win32_sema.c
View File

@ -23,6 +23,17 @@ static int maxSems; /* allocated size of mySemaSet array */
static void ReleaseSemaphores(int code, Datum arg);
/*
* Report amount of shared memory needed for semaphores
*/
Size
PGSemaphoreShmemSize(int maxSemas)
{
/* No shared memory needed on Windows */
return 0;
}
/*
* PGReserveSemaphores --- initialize semaphore support
*
@ -62,10 +73,10 @@ ReleaseSemaphores(int code, Datum arg)
/*
* PGSemaphoreCreate
*
* Initialize a PGSemaphore structure to represent a sema with count 1
* Allocate a PGSemaphore structure with initial count 1
*/
void
PGSemaphoreCreate(PGSemaphore sema)
PGSemaphore
PGSemaphoreCreate(void)
{
HANDLE cur_handle;
SECURITY_ATTRIBUTES sec_attrs;
@ -86,12 +97,14 @@ PGSemaphoreCreate(PGSemaphore sema)
if (cur_handle)
{
/* Successfully done */
*sema = cur_handle;
mySemSet[numSems++] = cur_handle;
}
else
ereport(PANIC,
(errmsg("could not create semaphore: error code %lu", GetLastError())));
(errmsg("could not create semaphore: error code %lu",
GetLastError())));
return (PGSemaphore) cur_handle;
}
/*
@ -106,7 +119,8 @@ PGSemaphoreReset(PGSemaphore sema)
* There's no direct API for this in Win32, so we have to ratchet the
* semaphore down to 0 with repeated trylock's.
*/
while (PGSemaphoreTryLock(sema));
while (PGSemaphoreTryLock(sema))
/* loop */ ;
}
/*
@ -127,7 +141,7 @@ PGSemaphoreLock(PGSemaphore sema)
* pending signals are serviced.
*/
wh[0] = pgwin32_signal_event;
wh[1] = *sema;
wh[1] = sema;
/*
* As in other implementations of PGSemaphoreLock, we need to check for
@ -182,9 +196,10 @@ PGSemaphoreLock(PGSemaphore sema)
void
PGSemaphoreUnlock(PGSemaphore sema)
{
if (!ReleaseSemaphore(*sema, 1, NULL))
if (!ReleaseSemaphore(sema, 1, NULL))
ereport(FATAL,
(errmsg("could not unlock semaphore: error code %lu", GetLastError())));
(errmsg("could not unlock semaphore: error code %lu",
GetLastError())));
}
/*
@ -197,7 +212,7 @@ PGSemaphoreTryLock(PGSemaphore sema)
{
DWORD ret;
ret = WaitForSingleObject(*sema, 0);
ret = WaitForSingleObject(sema, 0);
if (ret == WAIT_OBJECT_0)
{
@ -213,7 +228,8 @@ PGSemaphoreTryLock(PGSemaphore sema)
/* Otherwise we are in trouble */
ereport(FATAL,
(errmsg("could not try-lock semaphore: error code %lu", GetLastError())));
(errmsg("could not try-lock semaphore: error code %lu",
GetLastError())));
/* keep compiler quiet */
return false;