haiwan
/
ck
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '8ff8118ae7'
${ noResults }
ck/include/ck_epoch.h

157 lines
4.5 KiB
Raw Normal View History Unescape

ck_epoch: Remove debug output, update comments.
14 years ago
/*
legal: Update Copyright statements.
12 years ago
* Copyright 2011-2013 Samy Al Bahra.
ck_epoch: Remove debug output, update comments.
14 years ago
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#ifndef _CK_EPOCH_H
#define _CK_EPOCH_H
ck_epoch: Reference Fraser's thesis.
14 years ago
/*
* The implementation here is inspired from the work described in:
* Fraser, K. 2004. Practical Lock-Freedom. PhD Thesis, University
* of Cambridge Computing Laboratory.
*/
ck_epoch: Remove debug output, update comments.
14 years ago
#include <ck_cc.h>
#include <ck_pr.h>
#include <ck_stack.h>
#include <stdbool.h>
#ifndef CK_EPOCH_LENGTH
#define CK_EPOCH_LENGTH 4
#endif
ck_epoch: Support per-object destructors. This increases epoch per-object overhead to 16 bytes.
13 years ago
struct ck_epoch_entry;
typedef struct ck_epoch_entry ck_epoch_entry_t;
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
typedef void ck_epoch_cb_t(ck_epoch_entry_t *);
ck_epoch: Remove debug output, update comments.
14 years ago
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
/*
* This should be embedded into objects you wish to be the target of
* ck_epoch_cb_t functions (with ck_epoch_call).
*/
ck_epoch: Support per-object destructors. This increases epoch per-object overhead to 16 bytes.
13 years ago
struct ck_epoch_entry {
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
ck_epoch_cb_t *function;
ck_epoch: Support per-object destructors. This increases epoch per-object overhead to 16 bytes.
13 years ago
ck_stack_entry_t stack_entry;
ck_epoch: Remove debug output, update comments.
14 years ago
};
ck_epoch: Support per-object destructors. This increases epoch per-object overhead to 16 bytes.
13 years ago
/*
* Return pointer to ck_epoch_entry container object.
*/
#define CK_EPOCH_CONTAINER(T, M, N) CK_CC_CONTAINER(struct ck_epoch_entry, T, M, N)
ck_epoch: Remove debug output, update comments.
14 years ago
struct ck_epoch_record {
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
unsigned int state;
ck_epoch: Remove debug output, update comments.
14 years ago
unsigned int epoch;
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
unsigned int active;
ck_epoch: Redesigned and improved unit test and observability. ck_epoch_reclaim is now the replacement for ck_epoch_flush. ck_epoch_purge guarantees that all entries are reclaimed for the provided record before exiting. n_peak counter has been added, which provides the peak number of items across all reclamation lists. n_reclamations provides the number of reclamations across the lifetime of the record. These are cleared on unregister. ck_epoch_update has been renamed to ck_epoch_tick. Hazardous sections which mutate shared structures are now expected to begin with ck_epoch_write_begin and end with ck_epoch_end. Hazardous sections which read shared structures are now expected to begin with ck_epoch_read_begin and end with ck_epoch_end. ck_hp_free is now more aggressive. It will attempt a reclamation cycle any time the pending count is long. I should probably add a ck_hp_retire to have a version which allows for bulk updates to local reclamation lists.
14 years ago
unsigned int n_pending;
unsigned int n_peak;
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
unsigned long n_dispatch;
ck_stack_t pending[CK_EPOCH_LENGTH];
ck_epoch: Remove debug output, update comments.
14 years ago
ck_stack_entry_t record_next;
} CK_CC_CACHELINE;
typedef struct ck_epoch_record ck_epoch_record_t;
struct ck_epoch {
ck_epoch: Place epoch on a separate cache line.
14 years ago
unsigned int epoch;
char pad[CK_MD_CACHELINE - sizeof(unsigned int)];
ck_epoch: Remove debug output, update comments.
14 years ago
ck_stack_t records;
unsigned int n_free;
};
typedef struct ck_epoch ck_epoch_t;
ck_epoch: Barrier placement for RMO.
12 years ago
/*
* Marks the beginning of an epoch-protected section.
*/
ck_epoch: Remove debug output, update comments.
14 years ago
CK_CC_INLINE static void
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
ck_epoch_begin(ck_epoch_t *epoch, ck_epoch_record_t *record)
ck_epoch: Remove debug output, update comments.
14 years ago
{
ck_proxy: Add support for recursive epoch sections. Note that the global epoch won't tick over until the parent epoch section has completed.
13 years ago
/*
* Only observe new epoch if thread is not recursing into a read
* section.
*/
if (record->active == 0) {
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
unsigned int g_epoch = ck_pr_load_uint(&epoch->epoch);
ck_epoch: Emit fence instructions for TSO, do not emit for recursive calls. Unfortunately, there are still workloads which will not serialize. Recursive calls into ck_epoch_begin have no need for fence instructions.
12 years ago
/*
* It is possible for loads to be re-ordered before the store
* is committed into the caller's epoch and active fields.
* Execute a full barrier to serialize stores with respect to
* loads
*/
ck_proxy: Add support for recursive epoch sections. Note that the global epoch won't tick over until the parent epoch section has completed.
13 years ago
ck_pr_store_uint(&record->epoch, g_epoch);
ck_epoch: Emit fence instructions for TSO, do not emit for recursive calls. Unfortunately, there are still workloads which will not serialize. Recursive calls into ck_epoch_begin have no need for fence instructions.
12 years ago
ck_pr_store_uint(&record->active, 1);
ck_pr_fence_strict_memory();
return;
ck_proxy: Add support for recursive epoch sections. Note that the global epoch won't tick over until the parent epoch section has completed.
13 years ago
}
ck_pr_store_uint(&record->active, record->active + 1);
ck_epoch: Remove debug output, update comments.
14 years ago
return;
}
ck_epoch: Barrier placement for RMO.
12 years ago
/*
* Marks the end of an epoch-protected section.
*/
ck_epoch: Remove debug output, update comments.
14 years ago
CK_CC_INLINE static void
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
ck_epoch_end(ck_epoch_t *global, ck_epoch_record_t *record)
ck_epoch: Differentiate read/write epoch endings. ck_epoch_end is deprecated. Please use ck_epoch_read_end and ck_epoch_write_end instead.
13 years ago
{
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
(void)global;
ck_epoch: Differentiate read/write epoch endings. ck_epoch_end is deprecated. Please use ck_epoch_read_end and ck_epoch_write_end instead.
13 years ago
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
ck_pr_fence_memory();
ck_proxy: Add support for recursive epoch sections. Note that the global epoch won't tick over until the parent epoch section has completed.
13 years ago
ck_pr_store_uint(&record->active, record->active - 1);
ck_epoch: Remove debug output, update comments.
14 years ago
return;
}
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
/*
* Defers the execution of the function pointed to by the "cb"
* argument until an epoch counter loop. This allows for a
* non-blocking deferral.
*/
ck_epoch: Follow-up to previous commit. Some changes were not checked in.
14 years ago
CK_CC_INLINE static void
ck_epoch: Change to epoch semantics, bump grace period to 4.
12 years ago
ck_epoch_call(ck_epoch_t *epoch,
ck_epoch_record_t *record,
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
ck_epoch_entry_t *entry,
ck_epoch_cb_t *function)
ck_epoch: Remove debug output, update comments.
14 years ago
{
ck_epoch: Change to epoch semantics, bump grace period to 4.
12 years ago
unsigned int e = ck_pr_load_uint(&epoch->epoch);
unsigned int offset = e & (CK_EPOCH_LENGTH - 1);
ck_epoch: Remove debug output, update comments.
14 years ago
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
record->n_pending++;
entry->function = function;
ck_stack_push_spnc(&record->pending[offset], &entry->stack_entry);
ck_epoch: Remove debug output, update comments.
14 years ago
return;
}
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
void ck_epoch_init(ck_epoch_t *);
ck_epoch: Support per-object destructors. This increases epoch per-object overhead to 16 bytes.
13 years ago
ck_epoch_record_t *ck_epoch_recycle(ck_epoch_t *);
void ck_epoch_register(ck_epoch_t *, ck_epoch_record_t *);
ck_epoch: Remember to mark entry availability on unregister. Pointed out by Matt Johnson (johnso87@crhc....>.
12 years ago
void ck_epoch_unregister(ck_epoch_t *, ck_epoch_record_t *);
ck_epoch: Major redesign and rewrite. I had the pleasure of spending a significant amount of time at the most recent LPC with Mathieu Desnoyers and Paul McKenney. In discussing RCU semantics in relation to epoch reclamation, it was argued that epoch reclamation is a specialisation of RCU (rather than a generalization). In light of this discussion, I thought it would make more sense to not expose write-side synchronization semantics aside from ck_epoch_call (similar to RCU call), ck_epoch_poll (identical to tick), ck_epoch_barrier and ck_epoch_synchronization (similar to ck_epoch_synchronization). Writers will now longer have to use write-side epoch sections but can instead rely on epoch_barrier/synchronization for blocking semantics and ck_epoch_poll for old tick semantics. One advantage of this is we can avoid write-side recursion for certain workloads. Additionally, for infrequent writes, epoch_barrier and epoch_synchronization both allow for blocking semantics to be used so you don't have to pay the cost of epoch_entry for non-blocking dispatch. Example usage: e = stack_pop(mystack); ck_epoch_synchronize(...); free(e); read_begin and read_end has been replaced with ck_epoch_begin and ck_epoch_end. If multiple writers need SMR guarantees, then they can also use ck_epoch_begin and ck_epoch_end. Any dispatch in presence of multiple writers should be done with-in an epoch section (for now). There are some follow-up commits to come.
12 years ago
bool ck_epoch_poll(ck_epoch_t *, ck_epoch_record_t *);
void ck_epoch_synchronize(ck_epoch_t *, ck_epoch_record_t *);
void ck_epoch_barrier(ck_epoch_t *, ck_epoch_record_t *);
ck_epoch: Add ck_epoch_reclaim function. This function allows for explicit execution of all deferred callbacks in an epoch_record. The primary motivation is currently for performance profiling but there are other use-cases where best-effort semantics could be applied.
12 years ago
void ck_epoch_reclaim(ck_epoch_record_t *);
ck_epoch: Remove debug output, update comments.
14 years ago
#endif /* _CK_EPOCH_H */