On Thu, 24 Jun 1999, Alfred Perlstein wrote: > On Thu, 24 Jun 1999, Brian F. Feldman wrote: > > > On Thu, 24 Jun 1999, Alfred Perlstein wrote: > > > > > On Thu, 24 Jun 1999, Karl Denninger wrote: > > > > > > A simple start would be to explicitly put a macro or call in each > > > syscall to push down the lock. That way people can move that > > > macro farther and farther down in the syscall code path, hopefully > > > removing it entirely in some cases. I think having the call at > > > the beginning of each syscall would motivate people into doing that > > > sort of work. > > > > > > "Hey, y'know getppid() is safe, i'll just take the lock out." > > > "this function xxx() is safe until this point I can process a lot > > > before actually needing this lock..." > > > "y'know I just have a structure that's not accessable to any other calls > > > that i'm going to fill in, i'll just lift the lock right here" > > > "if I just do this something here, I really am re-entrant and safe.." > > > > > > Providing a simple api for spinlocks and mutexes would be very nice. > > > > > > > Something along the lines of how spl()s work? And mutex allocation like what > > we do with malloc types, maybe? > > I'm not sure what you mean by the refernce to malloc types, I just > thought something along the lines of mutex_t with an API > for trying, allocating, freeing and initializing them.
I meant something like an extensible set of mutex "groups", like our kernel malloc uses. New mutex types would be added. Instead of per- function mutexes, a single mutex "type" could be used for multiple functions that are the same in usage of sensitive resources. Just an idea... > > Also, some really interesting things could be done via per-CPU > resource pools to lower the amount of contention on objects. > > Pardon the niaveness of this idea, but things like per-CPU > malloc areas and each CPU haveing a queue for CPUs if > memory is free'd by a processor that down't "own" it. > Things like someone signalling another processor if one of its > free queues becomes full, or if a CPU finds its pool exhausted. > > -Alfred > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message