Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Don Y <this@isnotme.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: things i would ban from clc |
| Date | 2012-03-15 13:40 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <jjtk44$hih$1@speranza.aioe.org> (permalink) |
| References | (12 earlier) <jjo1lk$jrm$1@speranza.aioe.org> <87zkbktlvn.fsf@blp.benpfaff.org> <kfn1uowm6c4.fsf@x-alumni2.alumni.caltech.edu> <jjpim1$vka$1@speranza.aioe.org> <kfnobrylvt0.fsf@x-alumni2.alumni.caltech.edu> |
Hi Tim,
On 3/14/2012 2:25 PM, Tim Rentsch wrote:
>>> I assume most people in the group have seen this, but for those
>>> who have not:
>>>
>>> Threads Cannot be Implemented as a Library
>>>
>>> Boehm, Hans-J.
>>>
>>> HPL-2004-209
>>>
>>> Abstract: In many environments, multi-threaded code is written
>>> in a language that was originally designed without thread support
>>> (e.g. C), to which a library of threading primitives was
>>> subsequently added. There appears to be a general understanding
>>> that this is not the right approach. We provide specific
>>> arguments that a pure library approach, in which the compiler is
>>> designed independently of threading issues, cannot guarantee
>>> correctness of the resulting code. We first review why the
>>> approach almost works, and then examine some of the surprising
>>> behavior it may entail. We further illustrate that there are
>>> very simple cases in which a pure library-based approach seems
>>> incapable of expressing an efficient parallel algorithm. Our
>>> discussion takes place in the context of C with Pthreads, since
>>> it is commonly used, reasonably well specified, and does not
>>> attempt to ensure type-safety, which would entail even stronger
>>> constraints. The issues we raise are not specific to that
>>> context.
>>>
>>> http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
>>
>> I think the problem being addressed, here,
>
> Did you read the paper?
Yes, hence my comments. To take (roughly) the cases presented
in the paper:
4.1) You *know* when writing multithreaded code that
control to *any* shared object has to be arbitrated
(this is, IMO, one of the key points the article
tries to skirt... as if wanting NOT to have the
developer be concerned with these issues -- an
admirable goal but not one that rules out threading
libraries as a possible solution). The examples given
in this section show *no* explicit acknowledgement that
the objects/data are shared nor any mechanism to ensure
that sharing works (i.e., not even a library call is
present!)
4.2) is yet another example of the above. Except, in
addition to the lack of any formal access control
mechanism, there is now the acknowledgement that a
datum may span "objects". I.e., yet another case of
wanting to protect the programmer from things he might
have failed to notice (though still not anything that
precludes a library based solution)
4.3) Frankly, I don't see the problem here (too early
in the day?). Aside from the INEFFICIENCY that is
introduced... where is the code "broken"? OK, the
compiler's optimizations may have been unfortunate
but does the code perform as intended?
5.1) Makes the efficiency argument explicit -- and
goes to my comment regarding truly parallel implementations.
for (my_prime = start; my_prime < 10000; ++my_prime) {
if (!get(my_prime)) {
for (mult = my_prime; mult < 100000000; mult += my_prime) {
if (!get(mult)) {
set(mult);
}
}
}
}
is written *assuming* multiple threads can access the array
(sieve) hidden behind get()/set() inexpensively and concurrently.
The author then complains that the implementation of set()/get()
can cause problems -- for exactly the same reasons in 4.x.
I.e., the authors are advocating freeing the developer from
any concerns associated with implementing concurrency.
"Let's let the compiler consider all of these possible
cases and craft some rules that are *different* from the
rules a multithreaded programmer already SHOULD know..."
Yet, complain when safeguarding against those problems
(e.g., by invoking a mutex per shared object) becomes
"expensive": "Where's *my* free lunch??"
Sure, it would be delightful to *have* such protection
(i.e., scissors that automatically cover their blades
when they detect that you are "running with them").
But, I don't see how that PREVENTS a library based solution
from working.
E.g., wrap the internals of get()/set() with a lock.
The concurrency problems go away -- but performance
plummets. BECAUSE YOUR THREADS ARE COMPETING FOR TOO
MUCH DATA.
OTOH, having a thread doing this while another thread is
balancing your checkbook and still another is darning
your socks incurs NO performance penalty.
Yeah, its unfortunate that I can't get 500 digits of
precision in all of my math "for free". But, I don't
*expect* it to be free!
>> boil down to
>> removing the need for the developer to "take precautions"
>> (i.e., manually ensure that the compiler doesn't "get ahead
>> of him") along with wanting to be able to use the language
>> to *efficiently* implement truly parallel threads of
>> execution. [snip elaboration]
>
> The problem is the compiler is operating at the wrong level of
> abstraction. Whether the compiler "gets ahead" of a developer
> (a frightening concept in and of itself, but let's ignore
> that) doesn't matter, because the operating environment that
> (non-thread-aware) compilers generate code for doesn't make
> strong enough guarantees about inter-thread or inter-processor
> memory consistency. To get threads to work usably, at least
> part of the compiler needs to be aware of a lower level of
> abstraction, below the architectural level for a single
> process (which is where essentially all pre-thread-aware
> compilers operate).
I don't see that. I think that's only the case if you want
the compiler to be able to implement the safeguards *for* you.
And, I only see it pertaining to certain types of optimizations
(if the compiler doesn't make those optimizations, then your
code isn't at risk for them!)
I.e., I don't see how that PRECLUDES the use of a library.
Compilers are unaware of interrupts. An interrupt can occur
between any two instructions. Does that mean a you can't write
code in C that will operate in the presence of interrupts?
What it *does* mean is that anything that your code could be
doing that an interrupt might want to ASYNCHRONOUSLY interfere
with needs to be protected against that interference. Likewise,
anything your code wants to be able to *convey* to your ISR
needs to take precautions that the ISR sees "the whole picture"
and not just *part* of it.
Am I missing something, here?
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
things i would ban from clc jgk@panix.com (Joe keane) - 2012-03-11 23:05 +0000
Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-12 10:33 -0700
Re: things i would ban from clc gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-12 23:57 +0000
Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-12 18:44 +0100
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 12:26 -0700
Re: things i would ban from clc "osmium" <r124c4u102@comcast.net> - 2012-03-12 14:36 -0600
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 13:57 -0700
Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-12 17:34 -0400
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 15:00 -0700
Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-12 18:21 -0400
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 15:43 -0700
Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-12 23:53 +0100
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-12 17:17 -0700
Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 09:09 +0100
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 01:24 -0700
Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-13 05:59 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 10:55 -0700
Re: things i would ban from clc blp@cs.stanford.edu (Ben Pfaff) - 2012-03-13 11:07 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 11:25 -0700
Re: things i would ban from clc blp@cs.stanford.edu (Ben Pfaff) - 2012-03-13 11:32 -0700
Re: things i would ban from clc Keith Thompson <kst-u@mib.org> - 2012-03-13 12:18 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:13 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 13:49 -0700
Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 17:14 -0400
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 14:35 -0700
Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 18:09 -0400
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:06 -0700
Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 08:18 +0100
Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 10:07 +0100
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 12:41 -0700
Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 21:53 +0100
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 14:16 -0700
Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-18 07:14 +0100
Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-14 10:39 +0100
Re: things i would ban from clc Ben Pfaff <blp@cs.stanford.edu> - 2012-03-13 14:33 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 14:40 -0700
Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 16:25 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 00:51 -0700
Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-14 14:25 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 13:40 -0700
Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-18 17:05 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-23 11:59 -0700
Re: things i would ban from clc Robert Wessel <robertwessel2@yahoo.com> - 2012-03-23 17:02 -0500
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-23 16:51 -0700
Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-24 07:16 +0100
Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-27 11:26 -0700
Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-23 19:43 +0000
Re: things i would ban from clc Rui Maciel <rui.maciel@gmail.com> - 2012-03-23 19:45 +0000
Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 23:49 +0100
Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-24 11:54 +1300
Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:26 +0100
Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-26 07:31 -0700
Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-24 05:45 +0000
Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:31 +0100
Re: things i would ban from clc James Kuyper <jameskuyper@verizon.net> - 2012-03-13 14:34 -0400
Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 16:18 -0700
Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-14 08:18 +0100
Re: things i would ban from clc Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-14 14:06 -0700
Re: things i would ban from clc Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-15 15:22 +0000
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 12:26 -0700
Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-15 21:28 +0100
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 13:49 -0700
Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-15 16:36 +0000
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 12:16 -0700
Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-16 00:13 +0000
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-15 20:40 -0700
Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-13 01:52 -0700
Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-13 11:31 +0100
Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 11:41 +0100
Re: things i would ban from clc gwowen <gwowen@gmail.com> - 2012-03-13 06:06 -0700
Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 15:06 +0100
Re: things i would ban from clc ImpalerCore <jadill33@gmail.com> - 2012-03-13 07:46 -0700
Re: things i would ban from clc jacob navia <jacob@spamsink.net> - 2012-03-13 19:08 +0100
Re: things i would ban from clc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-13 13:20 +0000
Re: things i would ban from clc Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-13 20:41 +0100
Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-13 19:34 +0000
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 16:14 -0700
Re: things i would ban from clc Kaz Kylheku <kaz@kylheku.com> - 2012-03-13 23:28 +0000
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 21:18 -0700
Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-13 20:19 +1300
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-13 01:09 -0700
Re: things i would ban from clc Ian Collins <ian-news@hotmail.com> - 2012-03-13 21:32 +1300
Re: things i would ban from clc nick_keighley_nospam@hotmail.com - 2012-03-13 01:52 -0700
Re: things i would ban from clc "io_x" <a@b.c.invalid> - 2012-03-13 11:31 +0100
Re: things i would ban from clc nick_keighley_nospam@hotmail.com - 2012-03-14 01:18 -0700
Re: things i would ban from clc Don Y <this@isnotme.com> - 2012-03-14 12:09 -0700
Re: things i would ban from clc ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-03-14 13:01 -0700
csiph-web