Date: Wed, 28 Jun 2000 23:37:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: adsharma@sharmas.dhs.org Cc: smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <200006282337.QAA07749@usr08.primenet.com> In-Reply-To: <200006261647.JAA07306@sharmas.dhs.org> from "Arun Sharma" at Jun 26, 2000 09:47:31 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > Suffice it to say that I'm not convinced, nor am I convinced that > > mutex's around data structures is any different than critical > > sectioning. > > > > They are essentially the same thing, in that the critical section is > > almost always the code that deals with a particular (shared) data > > structure. > > I'd argue that mutexes around data structures allow more concurrency > than critical sections. It's the "lock the data - not code" principle. > Think of the case where there are a thousand instances of the > data structure and one critical section. That would be on allocating, deleting, and enumerating lists of structures. In your case, you'd lock the data to protect it from being manipulated; in mine, I'd lock the section of code that did the allocation, deletion, or iteration. I'd also be able to split a list of 60 locked entries into 6 list heads of 10 locked entries each. Now I'm more concurrent than you are, since I can have any number of readers without protecting the data, and you need to lock the list heads, the list structures, and the list entries. If I implement shared, single reader, multiple writer locks with intention modes, and then arrange them in a hierarchical arrangement, I can have variable granularity that changes as, for example, the number of entries in the proclist goes up and down. The price would be the same if the data were migrating willy-nilly between processors, but you wouldn't allow that. Instead, you would strive to seperate the contention domains, per processor. It is the inter-processor contention that is the problem. Think of it as trying for a virtual NUMA system. This approach will have to be supported for better than 8-way processing on Xeon and similar machines with "glueless" SMP implementations. See: http://www.intel.com/PentiumII/xeon/home.htm Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006282337.QAA07749>