> > * it's not that complicated: e.g. a truncate is identical to a write:
> > it needs exclusive access for the byte range (new EOF, current EOF).
>
> You *do* know how badly POSIX locks implementation sucks, right? Relying
> on it will kill any performance.
>
> > You don't need any new sync objects: only a normal spinlock for
> > additions
> > and removals from the collision list, and a wait queue for blocked
> > threads.
> > The collision list is similar to an extended semaphore: the "dec
> > sem->count"
> > is replaced with a check of all pending operations, so it's a very
> > flexible and "fine grained" lock.
>
> Too fine grained. You are adding the unneeded overhead.
I never thought about abusing POSIX locks for this. I thought about
an independant, lightweigth collision list. The lock structure
could lie on the stack, I think it could be quite efficient.
But the main problem is the overhead, but OTHO acquiring i_sem
for write operations would kill performance for large databases.
-- Manfred- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/