(Sorry, responding to the wrong message)
Paul E. McKenney wrote:
>
> I am concerned about this as well, and am beginning to suspect that I
> need to make a special-purpose primitive specifically for Jens that he
> can include with his code.
How about this?
struct xxx_struct {
int completed;
atomic_t ctr[2];
struct mutex mutex;
wait_queue_head_t wq;
};
void init_xxx_struct(struct xxx_struct *sp)
{
sp->completed = 0;
atomic_set(sp->ctr + 0, 1); // active
atomic_set(sp->ctr + 1, 0); // inactive
mutex_init(&sp->mutex);
init_waitqueue_head(&sp->wq);
}
int xxx_read_lock(struct xxx_struct *sp)
{
for (;;) {
int idx = sp->completed & 0x1;
if (likely(atomic_inc_not_zero(sp->ctr + idx)))
return idx;
}
}
void xxx_read_unlock(struct xxx_struct *sp, int idx)
{
if (unlikely(atomic_dec_and_test(sp->ctr + idx)))
wake_up(&sp->wq);
}
void synchronize_xxx(struct xxx_struct *sp)
{
int idx;
mutex_lock(&sp->mutex);
idx = ++sp->completed & 0x1;
smp_mb__before_atomic_inc();
atomic_inc(&sp->ctr + idx);
idx = !idx;
if (!atomic_dec_and_test(&sp->ctr + idx))
__wait_event(&sp->wq, !atomic_read(&sp->ctr + idx));
mutex_unlock(&sp->mutex);
}
Yes, cache thrashing... But I think this is hard to avoid if we want writer
to be fast.
I do not claim this is the best solution, but for some reason I'd like to
suggest something that doesn't need synchronize_sched(). What do you think
about correctness at least?
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
