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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/