This is gibberish. You have no idea what you're talking about.
jreiser@BitWagon.com said:
> But in the abstract, and more importantly in the mind of the
> maintainer of a lock-free SMP allocator
"lock-free SMP"? This is very nearly a self-contradiction. If you'd bother
looking at the allocators, guess what you'll see? You'll see locking.
> who is trying to allow
> simultaneous allocation and valgrind of the allocator,
There is no "allowing" simultaneous allocation and valgrind of the allocator.
> then such atomicity problems are real.
Bullshit, there are no such atomicity problems.
> If nothing else, then such a maintainer will invent his own VALGRIND_*
> usage to express simultaneous {allocator, valgrind} state transitions
> precisely.
A maintainer will invent valgrind primitives to express concepts that valgrind
doesn't know about?
> to express simultaneous {allocator, valgrind} state transitions
> precisely.
There are no simultaneous allocator and valgrind state transitions.
You really need to acquire a clue from somewhere.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:29 EST