Date: Tue, 20 Dec 2011 08:22:25 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: freebsd-threads@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <201112200822.26369.jhb@freebsd.org> In-Reply-To: <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com> References: <Your message of "Tue, 20 Dec 2011 09:48:12 GMT." <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> <3065.1324375763@critter.freebsd.dk> <4EF084A8.32369.B604AD16@s_sourceforge.nedprod.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, December 20, 2011 7:50:48 am Niall Douglas wrote: > On 20 Dec 2011 at 10:09, Poul-Henning Kamp wrote: > > > >1. Because [...] > > > > Nice and fine. > > > > But can you explain, why the job is done so half-assedly ? > > The job was NOT done half-arsed. If you had any experience of sitting > on these committees you would know how much dedication and effort is > put into standards, especially JTC1 SC22 subcommittees. Every single > API in there has been studied and pored over at length across > multiple years. > > Everything is the way it is for a good reason. If it doesn't make > sense to you that's most likely because you're not half as > experienced or clever as you think you are. If you really want to > know why something is the way it is, all discussion regarding all > points is documented in full. Mmmm, you might be well served to check up on the experience of some of the folks you are conversing with. Otherwise you risk reducing your credibility in the present forum. Also, to argue that "everything" in a standard is perfect is, eh, a bit of a stretch. There's a reason for the connotation associated with the phrase "design by committee". > > Why are fundamentally and necessary programming tools, such as a > > "assert this mutex is held" missing ? > > I think that was rejected due to concerns about introducing race > conditions if I remember correctly. You'll generally find there is no > easy way of checking the state of anything threading related for the > same reason. Err, no, there should be no races here. You cannot easily assert that a mutex is held by some other thread; however, if you use a thread-unique identifier as your lock cookie, then you can check to see if the current thread owns a mutex without any races (and this is a _very_ useful debugging technique in real-world applications). The reason I can think of why you might not specify this is if you want to support machines that have very limited support for atomic operations (e.g. only an exchange instruction or a single-bit test-and- set as opposed to a full-world test-and-set such as cmpxchg on x86 or cas on sparc). For those machines, you may be reduced to having a lock cookie of just 0 or 1 and you cannot distinguish the case of the current thread holding the lock versus another thread holding the lock. (It is hard to safely assert read locks for reader/writer locks for much the same reason as common lock- cookie encodings use a simple count for read locks.) However, that is due to a limitation of your abstract machine's atomic ops, not a race. > > Where did the ability to control a threads stacksize or other > > attributes go in thrd_create() ? > > I would assume that they were considered non portable due to vendor > objection. In particular, I remember an argument that thread > stacksize settings are dangerous and must be omitted. I guess you don't want any popular software (e.g. Python) to actually use your API then. :) Sadly, there is some code that wants to create a bazillion threads in a given process and there is other code that wants to create a few threads but use deep call stacks and/or put some large objects on the stack of those threads. There is not a single magical stack size that works equally well for both. I agree that it is very MD and hackish to let an application specify the size directly, but unfortunately the functionality is necessary. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112200822.26369.jhb>