Re: [PATCH] make cancel_rearming_delayed_work() reliable

Hello,

Jarek Poplawski wrote:
If we want to stick to more understanable, established ways,
why don't we use a global lock (not per cpu but per work or
per workqueue) for insert_work(), which would be really the
simplest construct here. Probably because some compromise is
needed. On the other hand many locks could be replaced with
elaborate constructs with atomic operations like this. But
for some reasons this usually isn't done.

IMHO it's better to get used to barriers, because, as seen
in this thread, even after finding better solution, the
problem of execution ordering didn't disappear. Another
"strange" question is: if these barriers are so tough, why
Oleg managed to do them seemingly right from the very first
time? But even if he would do some error here, I think it
should be easier to check for this one problem only, than to
risk the "stability" of the whole algorithm by changing more.
Of course now, after the time was spent anyway, this new
"old-way" is more attractive.

Well, it might be just because I'm used to what I call 'locked
enter/leave' model. If people don't find that easier to understand, no
objection from me and kudos to Oleg for getting it right from the beginning.

I think things can be made more similar to the locked enter/leave model
using the extra bit by putting manipulation and testing of the bit into
accesor functions, so readability was my primary concern not
performance. But, then again, we can probably make the barrier() model
readable enough too with proper accessor functions and plenty of
comments above them.

Yes, the good thing is Oleg can choose between two good
solutions here! (I don't envy him...)

As long as it's documented sufficiently, both are good. It's your
decision, Oleg. :-)

--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/