Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > things i would ban from clc

Reply
Thread Tools

things i would ban from clc

 
 
Ian Collins
Guest
Posts: n/a
 
      03-23-2012
On 03/24/12 11:49 AM, Jens Gustedt wrote:
> Am 03/23/2012 08:43 PM, schrieb Kaz Kylheku:
>
>> A multi-threading API in which a thread cannot pass a pointer to automatic
>> storage into some module, such that this module can then execute code on
>> another thread which accesses that memory, is about as useful as
>> tits on a bull.

>
> Yes, it is probably quite useless. On the other hand C11 says in 6.2.4
> p 5
>
> "The result of attempting to indirectly access an object with
> automatic storage duration from a thread other than the one with which
> the object is associated is implementation-defined."
>
> So an implementation of C11 may not allow this, as long as it
> documents its behavior properly.


Sometimes I think the standard allows implementations too much latitude!
I'm not aware of any threading implementation that doesn't use a
shared address space. The use of a shared address space is often used
as one of the conditions that differentiate between a threading and a
process model.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Don Y
Guest
Posts: n/a
 
      03-23-2012
Hi Robert,

On 3/23/2012 3:02 PM, Robert Wessel wrote:

> No, you're missing the point. C, as defined by the standard (at least
> up to C11 with threading support), does *not* define a language that
> can be reliably combined with a threading library, and expected to
> produce *any* defined, or even consistent, results.
>
> Threading-with-a-library works *only* if the implementation makes a
> number of additional promises about the behavior of the program,
> promises that are *not* part of the standard (again excepting C11 with
> __STDC_NO_THREADS__ undefined).
>
> Now threading obviously works with C in many cases, but that's just
> because the compiler writers have, either by choice or accident,
> implemented the required semantics that will make threading work
> (consider the word tearing issues mentioned in the paper). It's not
> something you can generically expect of C implementations.


So, what *specific* language in the specification (pre-2011)
gives the compiler writer latitude to make the following
"misbehave" (pseudo-code):

...
x = y = 0
spawn(A)
spawn(B)
...
begin_atom()
printf("%d %d", x, y)
end_atom()
...



A()
{
...
begin_atom()
x=1
y=2
end_atom()
...
}

B()
{
...
begin_atom()
x=3
y=4
end_atom()
...
}

I.e., anything other than the output of "0 0", "1 2" or "3 4"
would be considered "misbehaving".

And, specifically, why *can't* {begin,end}_atom() provide
the (obvious) functionality?

[OK, language lawyers... strut your stuff! :> ]

> The performance issues are separate. As are issues of programmers
> managing to get threading correct.


 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      03-24-2012
On 2012-03-23, Jens Gustedt <(E-Mail Removed)> wrote:
> Am 03/23/2012 08:43 PM, schrieb Kaz Kylheku:
>
>> A multi-threading API in which a thread cannot pass a pointer to automatic
>> storage into some module, such that this module can then execute code on
>> another thread which accesses that memory, is about as useful as
>> tits on a bull.

>
> Yes, it is probably quite useless. On the other hand C11 says in 6.2.4
> p 5
>
> "The result of attempting to indirectly access an object with
> automatic storage duration from a thread other than the one with which
> the object is associated is implementation-defined."


This kind of waffling is pointless word semantics. Regardless of whether you
require this, or allow implementations to duck out of it, there will be the
pretty much exactly the same implementations in the world with the same
capabilities.

It's just a question of whether they are marked as nonconforming
on this account, or conforming but with a reduced functionality.

To someone coding in the proverbial trenches, it makes no difference.

Morally speaking, implementations that break stuff like this shuld be deemed
nonconforming, in a kind of "hall of shame".

Standards should be bold and just require stuff to work, and not waste words on
waffling.
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      03-24-2012
Am 03/23/2012 11:54 PM, schrieb Ian Collins:
>> Yes, it is probably quite useless. On the other hand C11 says in 6.2.4
>> p 5
>>
>> "The result of attempting to indirectly access an object with
>> automatic storage duration from a thread other than the one with which
>> the object is associated is implementation-defined."
>>
>> So an implementation of C11 may not allow this, as long as it
>> documents its behavior properly.

>
> Sometimes I think the standard allows implementations too much latitude!


usually they have the simple reason that there is some implementation
that they want to cover

> I'm not aware of any threading implementation that doesn't use a shared
> address space. The use of a shared address space is often used as one
> of the conditions that differentiate between a threading and a process
> model.


No, no, that is not what it says. Statically allocated and malloc'ed
objects *must* work. It is just that an implementation might forbit a
thread to peek into the "local variables" of another thread. I could
imagine that this can be used on special hardware with per cpu
memory. Think of implementing a thread model on a graphics card, for
example.

But I agree that this is nothing I'd like to program

Jens


 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      03-24-2012
Am 03/24/2012 06:45 AM, schrieb Kaz Kylheku:
> On 2012-03-23, Jens Gustedt <(E-Mail Removed)> wrote:
>> Am 03/23/2012 08:43 PM, schrieb Kaz Kylheku:
>>
>>> A multi-threading API in which a thread cannot pass a pointer to automatic
>>> storage into some module, such that this module can then execute code on
>>> another thread which accesses that memory, is about as useful as
>>> tits on a bull.

>>
>> Yes, it is probably quite useless. On the other hand C11 says in 6.2.4
>> p 5
>>
>> "The result of attempting to indirectly access an object with
>> automatic storage duration from a thread other than the one with which
>> the object is associated is implementation-defined."

>
> This kind of waffling is pointless word semantics. Regardless of whether you
> require this, or allow implementations to duck out of it, there will be the
> pretty much exactly the same implementations in the world with the same
> capabilities.
>
> It's just a question of whether they are marked as nonconforming
> on this account, or conforming but with a reduced functionality.
>
> To someone coding in the proverbial trenches, it makes no difference.
>
> Morally speaking, implementations that break stuff like this shuld be deemed
> nonconforming, in a kind of "hall of shame".
>
> Standards should be bold and just require stuff to work, and not waste words on
> waffling.


You are ranting a bit quickly, I find.

Such a thing partially covers existing practice for programming e.g on
GPUs, where you have something like global memory that all PE can
access, statically identified of some sort or malloced, and local
memory that is restricted to PE and thus to the thread.

I am personally not a great fan of CUDA but if one day they could map
the new thread model on this, this would probably a big progress.

Jens
 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      03-26-2012
On Mar 23, 11:54*pm, Ian Collins <(E-Mail Removed)> wrote:

> Sometimes I think the standard allows implementations too much latitude!
> * I'm not aware of any threading implementation that doesn't use a
> shared address space. *The use of a shared address space is often used
> as one of the conditions that differentiate between a threading and a
> process model.


But one could imagine a distributed system where heap and static
allocations refer to some centralised datastore (possibly locally
cached, with some higher-level central constraints to maintain
consistency).[0] "Threads" are then local processes and sharable-
pointers are opaque references to the central store, and the "memory
space" spanned by these references is quite distinct from those used
by process-local variables.

It's a little far fetched, but I'd imagine the standard writers had
something in mind when they made it implementation defined (as opposed
to undefined).

[0] Please don't make me say "cloud"
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      03-27-2012
Don Y <(E-Mail Removed)> writes:

> [snip]


I echo the comments of Robert Wessel, whose response
matches my perception.

Beyond that, your reply seems largely nonresponsive and
simply repetitive of earlier comments. Usually I think
there is not much value in trying to respond to someone
who is not being responsive. May I suggest that you
put less effort into arguing, and more into reading and
listening carefully?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
More posts in clc than in clc++ ? Tony C Programming 6 02-10-2009 01:16 PM
vs2005 publish website doing bad things, bad things =?Utf-8?B?V2lsbGlhbSBTdWxsaXZhbg==?= ASP .Net 1 10-25-2006 06:18 PM
Multi-posting clc++ and clc++m (was: Multiply inherit from classes with conflicting function names) Alf P. Steinbach C++ 1 05-26-2006 03:58 AM
Visual C++ 7.1 INTERNAL COMPILER ERROR -- crossposted clc++ and microsoft.public.vstudio.general Alf P. Steinbach C++ 11 05-06-2004 11:28 PM
For the programmers among you: Top 12 Things A Klingon Programmer Would Say Mavra Chang Computer Support 11 02-20-2004 04:17 AM



Advertisments