1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* spin.c
|
2001-09-29 06:02:27 +02:00
|
|
|
* Hardware-independent implementation of spinlocks.
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* For machines that have test-and-set (TAS) instructions, s_lock.h/.c
|
2014-05-06 18:12:18 +02:00
|
|
|
* define the spinlock implementation. This file contains only a stub
|
2002-05-05 02:03:29 +02:00
|
|
|
* implementation for spinlocks using PGSemaphores. Unless semaphores
|
|
|
|
* are implemented in a way that doesn't involve a kernel call, this
|
2001-09-29 06:02:27 +02:00
|
|
|
* is too slow to be very useful :-(
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2000-11-29 00:27:57 +01:00
|
|
|
*
|
2016-01-02 19:33:40 +01:00
|
|
|
* Portions Copyright (c) 1996-2016, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/storage/lmgr/spin.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2014-01-09 02:58:22 +01:00
|
|
|
#include "storage/pg_sema.h"
|
2001-09-29 06:02:27 +02:00
|
|
|
#include "storage/spin.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-05-31 02:28:42 +02:00
|
|
|
|
2014-09-01 00:03:53 +02:00
|
|
|
#ifndef HAVE_SPINLOCKS
|
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed number of semaphores (by default, 1024)
from the operating system and multiplex all the spinlocks that get
created onto them. This could self-deadlock if a process attempted
to acquire more than one spinlock at a time, but since processes
aren't supposed to execute anything other than short stretches of
straight-line code while holding a spinlock, that shouldn't happen.
One motivation for this change is that, with the introduction of
dynamic shared memory, it may be desirable to create spinlocks that
last for less than the lifetime of the server. Without this change,
attempting to use such facilities under --disable-spinlocks would
quickly exhaust any supply of available semaphores. Quite apart
from that, it's desirable to contain the quantity of semaphores
needed to run the server simply on convenience grounds, since using
too many may make it harder to get PostgreSQL running on a new
platform, which is mostly the point of --disable-spinlocks in the
first place.
Patch by me; review by Tom Lane.
2014-01-09 00:49:14 +01:00
|
|
|
PGSemaphore SpinlockSemaArray;
|
2014-09-01 00:03:53 +02:00
|
|
|
#endif
|
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed number of semaphores (by default, 1024)
from the operating system and multiplex all the spinlocks that get
created onto them. This could self-deadlock if a process attempted
to acquire more than one spinlock at a time, but since processes
aren't supposed to execute anything other than short stretches of
straight-line code while holding a spinlock, that shouldn't happen.
One motivation for this change is that, with the introduction of
dynamic shared memory, it may be desirable to create spinlocks that
last for less than the lifetime of the server. Without this change,
attempting to use such facilities under --disable-spinlocks would
quickly exhaust any supply of available semaphores. Quite apart
from that, it's desirable to contain the quantity of semaphores
needed to run the server simply on convenience grounds, since using
too many may make it harder to get PostgreSQL running on a new
platform, which is mostly the point of --disable-spinlocks in the
first place.
Patch by me; review by Tom Lane.
2014-01-09 00:49:14 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Report the amount of shared memory needed to store semaphores for spinlock
|
|
|
|
* support.
|
|
|
|
*/
|
|
|
|
Size
|
|
|
|
SpinlockSemaSize(void)
|
|
|
|
{
|
|
|
|
return SpinlockSemas() * sizeof(PGSemaphoreData);
|
|
|
|
}
|
|
|
|
|
2003-12-23 19:13:17 +01:00
|
|
|
#ifdef HAVE_SPINLOCKS
|
2000-11-29 00:27:57 +01:00
|
|
|
|
|
|
|
/*
|
2002-05-05 02:03:29 +02:00
|
|
|
* Report number of semaphores needed to support spinlocks.
|
2000-11-29 00:27:57 +01:00
|
|
|
*/
|
2002-05-05 02:03:29 +02:00
|
|
|
int
|
|
|
|
SpinlockSemas(void)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2002-05-05 02:03:29 +02:00
|
|
|
return 0;
|
2000-11-29 00:27:57 +01:00
|
|
|
}
|
2003-12-23 19:13:17 +01:00
|
|
|
#else /* !HAVE_SPINLOCKS */
|
2000-11-29 00:27:57 +01:00
|
|
|
|
|
|
|
/*
|
2002-05-05 02:03:29 +02:00
|
|
|
* No TAS, so spinlocks are implemented as PGSemaphores.
|
2000-11-29 00:27:57 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2002-05-05 02:03:29 +02:00
|
|
|
* Report number of semaphores needed to support spinlocks.
|
2000-11-29 00:27:57 +01:00
|
|
|
*/
|
2002-05-05 02:03:29 +02:00
|
|
|
int
|
|
|
|
SpinlockSemas(void)
|
2000-11-29 00:27:57 +01:00
|
|
|
{
|
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
|
|
|
return NUM_SPINLOCK_SEMAPHORES + NUM_ATOMICS_SEMAPHORES;
|
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed number of semaphores (by default, 1024)
from the operating system and multiplex all the spinlocks that get
created onto them. This could self-deadlock if a process attempted
to acquire more than one spinlock at a time, but since processes
aren't supposed to execute anything other than short stretches of
straight-line code while holding a spinlock, that shouldn't happen.
One motivation for this change is that, with the introduction of
dynamic shared memory, it may be desirable to create spinlocks that
last for less than the lifetime of the server. Without this change,
attempting to use such facilities under --disable-spinlocks would
quickly exhaust any supply of available semaphores. Quite apart
from that, it's desirable to contain the quantity of semaphores
needed to run the server simply on convenience grounds, since using
too many may make it harder to get PostgreSQL running on a new
platform, which is mostly the point of --disable-spinlocks in the
first place.
Patch by me; review by Tom Lane.
2014-01-09 00:49:14 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize semaphores.
|
|
|
|
*/
|
|
|
|
extern void
|
|
|
|
SpinlockSemaInit(PGSemaphore spinsemas)
|
|
|
|
{
|
2014-05-06 18:12:18 +02:00
|
|
|
int i;
|
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
|
|
|
int nsemas = SpinlockSemas();
|
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed number of semaphores (by default, 1024)
from the operating system and multiplex all the spinlocks that get
created onto them. This could self-deadlock if a process attempted
to acquire more than one spinlock at a time, but since processes
aren't supposed to execute anything other than short stretches of
straight-line code while holding a spinlock, that shouldn't happen.
One motivation for this change is that, with the introduction of
dynamic shared memory, it may be desirable to create spinlocks that
last for less than the lifetime of the server. Without this change,
attempting to use such facilities under --disable-spinlocks would
quickly exhaust any supply of available semaphores. Quite apart
from that, it's desirable to contain the quantity of semaphores
needed to run the server simply on convenience grounds, since using
too many may make it harder to get PostgreSQL running on a new
platform, which is mostly the point of --disable-spinlocks in the
first place.
Patch by me; review by Tom Lane.
2014-01-09 00:49:14 +01:00
|
|
|
|
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
|
|
|
for (i = 0; i < nsemas; ++i)
|
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed number of semaphores (by default, 1024)
from the operating system and multiplex all the spinlocks that get
created onto them. This could self-deadlock if a process attempted
to acquire more than one spinlock at a time, but since processes
aren't supposed to execute anything other than short stretches of
straight-line code while holding a spinlock, that shouldn't happen.
One motivation for this change is that, with the introduction of
dynamic shared memory, it may be desirable to create spinlocks that
last for less than the lifetime of the server. Without this change,
attempting to use such facilities under --disable-spinlocks would
quickly exhaust any supply of available semaphores. Quite apart
from that, it's desirable to contain the quantity of semaphores
needed to run the server simply on convenience grounds, since using
too many may make it harder to get PostgreSQL running on a new
platform, which is mostly the point of --disable-spinlocks in the
first place.
Patch by me; review by Tom Lane.
2014-01-09 00:49:14 +01:00
|
|
|
PGSemaphoreCreate(&spinsemas[i]);
|
|
|
|
SpinlockSemaArray = spinsemas;
|
2000-11-29 00:27:57 +01:00
|
|
|
}
|
1997-08-19 23:40:56 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2016-04-17 01:53:38 +02:00
|
|
|
* s_lock.h hardware-spinlock emulation using semaphores
|
|
|
|
*
|
|
|
|
* We map all spinlocks onto a set of NUM_SPINLOCK_SEMAPHORES semaphores.
|
|
|
|
* It's okay to map multiple spinlocks onto one semaphore because no process
|
|
|
|
* should ever hold more than one at a time. We just need enough semaphores
|
|
|
|
* so that we aren't adding too much extra contention from that.
|
|
|
|
*
|
|
|
|
* slock_t is just an int for this implementation; it holds the spinlock
|
|
|
|
* number from 1..NUM_SPINLOCK_SEMAPHORES. We intentionally ensure that 0
|
|
|
|
* is not a valid value, so that testing with this code can help find
|
|
|
|
* failures to initialize spinlocks.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-11-29 00:27:57 +01:00
|
|
|
|
1999-10-06 23:58:18 +02:00
|
|
|
void
|
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
|
|
|
s_init_lock_sema(volatile slock_t *lock, bool nested)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2014-05-06 18:12:18 +02:00
|
|
|
static int counter = 0;
|
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed number of semaphores (by default, 1024)
from the operating system and multiplex all the spinlocks that get
created onto them. This could self-deadlock if a process attempted
to acquire more than one spinlock at a time, but since processes
aren't supposed to execute anything other than short stretches of
straight-line code while holding a spinlock, that shouldn't happen.
One motivation for this change is that, with the introduction of
dynamic shared memory, it may be desirable to create spinlocks that
last for less than the lifetime of the server. Without this change,
attempting to use such facilities under --disable-spinlocks would
quickly exhaust any supply of available semaphores. Quite apart
from that, it's desirable to contain the quantity of semaphores
needed to run the server simply on convenience grounds, since using
too many may make it harder to get PostgreSQL running on a new
platform, which is mostly the point of --disable-spinlocks in the
first place.
Patch by me; review by Tom Lane.
2014-01-09 00:49:14 +01:00
|
|
|
|
2016-04-17 01:53:38 +02:00
|
|
|
*lock = ((++counter) % NUM_SPINLOCK_SEMAPHORES) + 1;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1999-10-06 23:58:18 +02:00
|
|
|
void
|
2000-11-29 00:27:57 +01:00
|
|
|
s_unlock_sema(volatile slock_t *lock)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2016-04-17 01:53:38 +02:00
|
|
|
int lockndx = *lock;
|
|
|
|
|
|
|
|
if (lockndx <= 0 || lockndx > NUM_SPINLOCK_SEMAPHORES)
|
|
|
|
elog(ERROR, "invalid spinlock number: %d", lockndx);
|
|
|
|
PGSemaphoreUnlock(&SpinlockSemaArray[lockndx - 1]);
|
2000-11-29 00:27:57 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-11-29 00:27:57 +01:00
|
|
|
bool
|
|
|
|
s_lock_free_sema(volatile slock_t *lock)
|
|
|
|
{
|
2002-05-05 02:03:29 +02:00
|
|
|
/* We don't currently use S_LOCK_FREE anyway */
|
|
|
|
elog(ERROR, "spin.c does not support S_LOCK_FREE()");
|
|
|
|
return false;
|
2000-11-29 00:27:57 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-11-29 00:27:57 +01:00
|
|
|
int
|
|
|
|
tas_sema(volatile slock_t *lock)
|
|
|
|
{
|
2016-04-17 01:53:38 +02:00
|
|
|
int lockndx = *lock;
|
|
|
|
|
|
|
|
if (lockndx <= 0 || lockndx > NUM_SPINLOCK_SEMAPHORES)
|
|
|
|
elog(ERROR, "invalid spinlock number: %d", lockndx);
|
2000-11-29 00:27:57 +01:00
|
|
|
/* Note that TAS macros return 0 if *success* */
|
2016-04-17 01:53:38 +02:00
|
|
|
return !PGSemaphoreTryLock(&SpinlockSemaArray[lockndx - 1]);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2003-12-23 19:13:17 +01:00
|
|
|
#endif /* !HAVE_SPINLOCKS */
|