On Thu, Sep 07, 2000 at 02:44:26PM +0100, David Howells wrote:
>
> Andi Kleen <ak@suse.de> wrote:
> > I did not see the lock. Where is it ?
>
> Well, on the bit functions set_bit() and test_and_clear_bit(), the macro
> inserts an appopriate locking instruction into the assembly.
But that's not race free on SMP. Two CPUs can set the bit in parallel
and you'll never notice. You would need at least a protecting spinlock
between the test bit and set bit (or a cmpxchg on x86)
> On the wait queue, the wait_queue structure includes
That also does not help for protecting your objects, it only protects
the wait queue.
>
> > I don't know too much about Win32, but I assume you could always share it
> > lazily on demand (assuming the most mutexes are only used by threads, not
> > between processes)
>
> How does a second process know when a first process has created one, unless
> its name is published. And if you do it that way, they then have to negotiate
> in some way to elevate it to a kernel object.
The processes look it up in a shared name table (shmem). Yes they have
to negoitate in this case -- it'll only be a win when they usually do not
share.
>
> > But the number of objects is not restricted, no ?
>
> Currently each the handle map for each process is restricted to a single page
> less a header. This places a rough limit on the number of objects to number of
> processes (not threads) * ~1020. Additionally, some objects (like mutexes) can
> beshared and so several handle map entries point to a single object.
>
> However, a hard limit can easily be imposed, and may best be.
Probably, it is a DoS.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:29 EST