Subj : Re: Adding thread support for C... To : comp.programming.threads From : David Hopwood Date : Tue Jul 26 2005 01:55 am Joe Seigh wrote: > Mayan Moudgill wrote: >> Joe Seigh wrote: >>> Mayan Moudgill wrote: >>> >>> What you won't get is support for writing your own synchronization >>> api's, Not unless you can construct them out of the synchronization >>> functions they give you. Probablly something like the atomic stuff >>> in JSR 166. You might want to take a look at that. >> >> So what synchronization APIs would you like to see supported? > > I deal with various issues depending on what I'm doing at the time. > I don't think it's worth my time trying to formalize what thread support > by C should be given it would take a lot of time and effort. I don't > think I could counter the agendas others are pushing plus the tendency > of threading api implementors to have a low opinion of other peoples > thread programming skills. This leads to the deliberate omission of > low level primitives and the inclusion of only the high level api's > favored by the thread api designers. Those of us who argue against direct use by applications of low-level primitives dependent on particular machine-level shared memory models, are not doing so simply because we have plucked an agenda out of thin air. The arguments supporting this view are: - designing correct lock-free algorithms is difficult even for experts. - most application programmers are not experts in this area; observation and experience, not just opinion, suggests that they frequently misunderstand how to use these primitives either correctly or efficiently. - the more such APIs attempt to optimize for particular machines, the more complex and nonportable they become. Some proposed primitives (e.g. data-dependent barriers) seem AFAICS to be based more on coincidental properties of the implementation of current processors than on any documented and well-understood memory model. - if these primitives were used only by language implementations, operating systems, and to provide higher-level APIs, the complexity cost and the porting effort would be amortized over all the apps using those languages/OSes/APIs. If they are used directly by applications, these costs have to be paid per-appication. - dependence on specific current machine-level memory models by applications will make it more difficult to support those applications on future hardware. - for many, probably most, multi-threaded applications, using these primitives would not improve performance significantly or have any other benefit. There's quite a close analogy between depending on low-level shared memory primitives, and the kind of direct hardware access, bypassing the OS, that many MS-DOS programs used to do. Just as in that case, emulating the behaviour of current machines in order to support those applications will be possible, but it will be complex, unreliable, and slow. The complexity is the most serious problem. -- David Hopwood .