rwatson_at_freebsd.org wrote: > I appreciate that not everyone is a fan of mutex synchronization, > but "mutex hell" is a bit of an odd description: most bugs I see > getting reported (and fixed) aren't even locking-related. They're > generally a property of lack of testing exposure for more obscure > features or edge cases that are hard to test for without a wide > testing base, such as edge-case hardware, bugs associated with > longer run times, or a recently introduced feature, etc. Well, mutex hell is more of a humorous description, but unfortunately it is not too far from what is becoming a reality. I believe that the path the FreeBSD Project has taken with the 5.x branch (not only in regard to mutex locking but in general) has made things far too complex in ways that make even seasoned hardcore developers such as yourself unwilling to touch certain subsystems because only one or two people really understand that system well enough to introduce only a few (instead of a few dozen) critical bugs when changing that subsystem. Or do you want to tell me that you could go right in and get the critical section related stuff sorted out on your own without John Baldwin and Stephan Uphoff in order to get to merge your UMA related changes? :-) I've been examining kernel sources in greater detail these past few days and from what I've seen so far I believe certain subsystems should just be rewritten from scratch in order to simplify things in terms of solving MP problems and UP performance (burning a lot of unnecessary cycles on every mutex release and the like is just not acceptable, IMHO). Rewritting the IPI code and the scheduler should be a good start, but I doubt anyone from the Core team would even consider that because you've all invested so much into what is in place now. As you keep working on the same things you've been working on for years things get more and more complex and you become more and more resistant to change, while potential developers become more and more discouraged and in the end things might get very stale with only a handful overworked developers who won't be able to see the forest for the trees. I do not mean to start a flame war or anything, this is just my opinion, I do have a lot of respect for all of you guys working hard on the 5.x and the 6.x branches, I just politely disagree with the direction in which the project is heading. :-) ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.netReceived on Mon Feb 07 2005 - 17:42:48 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:27 UTC