Pyro device driver API
|
Reader/writer consistent mechanism without starving writers. More...
Data Structures | |
struct | SeqLock_s |
struct | seqcount |
Macros | |
#define | smp_rmb() __asm__ __volatile__( "lock; addl $0,0(%%esp)" ::: "memory" ) |
#define | smp_wmb() __asm__ __volatile__( "" : : : "memory" ) |
#define | SEQ_LOCK(var, name) SeqLock_s var = { 0, INIT_SPIN_LOCK( name ) } |
#define | INIT_SEQ_LOCK(name) { 0, INIT_SPIN_LOCK( name ) } |
#define | SEQCNT_ZERO { 0 } |
#define | seqcount_init(x) do { *(x) = (seqcount_t) SEQCNT_ZERO; } while (0) |
#define | read_seqbegin_cli(lock, flags) ({ flags = cli(); read_seqbegin(lock); }) |
#define | read_seqretry_restore(lock, iv, flags) |
Typedefs | |
typedef struct seqcount | seqcount_t |
Reader/writer consistent mechanism without starving writers.
This type of lock for data where the reader wants a consitent set of information and is willing to retry if the information changes. Readers never block but they may have to retry if a writer is in progress. Writers do not wait for readers.
This is not as cache friendly as brlock. Also, this will not work for data that contains pointers, because any writer could invalidate a pointer that a reader was following.
Expected reader usage: do { seq = read_seqbegin(&foo); ... } while (read_seqretry(&foo, seq));
On non-SMP the spin locks disappear but the writer still needs to increment the sequence variables because an interrupt routine could change the state of the data.
Based on x86_64 vsyscall gettimeofday by Keith Owens and Andrea Arcangeli
#define read_seqretry_restore | ( | lock, | |
iv, | |||
flags | |||
) |