Date: Thu, 1 Oct 1998 12:02:33 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: nash@mcs.net (Alex Nash) Cc: jb@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread uthread_gc.c Makefile.inc uthread_init.c uthread_find_thread.c uthread_kern.c uthread_cre Message-ID: <199810010202.MAA07069@cimlogic.com.au> In-Reply-To: <19980930192221.S9697@pr.mcs.net> from Alex Nash at "Sep 30, 98 07:22:21 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Alex Nash wrote: > On Tue, Sep 29, 1998 at 11:14:00PM -0700, John Birrell wrote: > > jb 1998/09/29 23:13:59 PDT > > > > Modified files: > > lib/libc/stdlib malloc.c > > Log: > > Delete the XXX comments that refer to spinlock recursion. > > What are the semantics that allow these functions to obtain the spinlock > and not release it before returning? If that were to happen, it would show up a bug in either the malloc/realloc/ free code or a function called from within that code. The check that phk has in his code simply allows him to find when his code is broken by other people's changes. If you ever see the recursion warning, someone has broken the code. So going to great pains to get the locking semantics right for broken code is a waste of time. > > > The malloc/free/ > > realloc functions check for recursion within the malloc code itself. In > > a thread-safe library, the single spinlock ensures that no two threads > > go inside the protected code at the same time. > > It doesn't prevent the *same* thread from being inside the protected > code more than once (e.g. due to a signal). The *same* thread will lock against itself. A deadlock. That's a bug. The behaviour of malloc/realloc/free is the same whether threaded or not. The thread implementation has to behave in such a way that it doesn't allow the same thread to go back into the malloc/realloc/free code if it has already taken the lock. The only time this would occur is if the thread kernel was trying to go in there. I've moved that code so that it doesn't need to do that anymore. > > > The thread implementation > > is responsible for ensuring that the spinlock does in fact protect malloc. > > There was a window of opportunity in which this was not the case. I'll fix > > that with a commit RSN. > > Because our spinlock allows a single thread to recursively obtain the > lock without counting, it's conceivable that the following scenario > might occur: It doesn't. A thread can't tell from the spinlock value if _it_ locked the lock or another thread did. All that it knows is that the lock is locked. The thread implementation has to remember what it has locked in order to avoid deadlocks. This means that there is very little performance hit in protecting code with spinlocks. The expectation is that the spinlock will only be locked for a short time. Locks with longer duration require mutex and condition variable pairs so that a blocked thread is put to sleep until the mutex becomes available. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810010202.MAA07069>