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

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message