«

On Jan 13, 6:32*am, Rui Maciel <rui.mac...@gmail.com> wrote:
> Ian Collins wrote:
> >> If you want all these extra things by all means add them to C++ and use
> >> C++ just don't mess about with C.
>
> > Well if C is to have a future on all but the smallest single core
> > processors, threading should be considered, at least as an option.
>
> What's wrong with relying on standards for threads, such as pthreads? *
> There is no reason to push something into a particular standard when that
> very same feature is already defined by another standard.

Several reasons.

First, I think we'd all like an implemented and portable threading
interface so we don't have to roll our own abstraction layer. There's
a lot of subtle nuance in the several threading libraries which make
it non-trivial to wrap.

Second, threading really ought to be part of the programming language
standard as it directly affects and constrains the code generation of
the compiler. A library like a GUI doesn't impose any particular
noteworthy restrictions on the compiler, but threading is inextricably
tied to compilation, optimization, and code generation.

Third, from my knowledge of win32 threads, pthreads, and the barriers
of the linux kernel, I personally very much welcome this new standard
as it's much more formalized. There is such a lack of knowledge in the
community as to how threading actually works. I meet people every day
who think that volatile is still a portably useful threading
primitive. Trying to reason about how the compiler operate when
throwing inline assembly at it with pthreads is also quite difficult.
The new standard is much more complete, sane, and useful.

I've seen people using gcc inline assembly to do a read and write
barriers, and argue whether the "memory" clobber is used or not, and
whether volatile will make it work in the absence of the "memory"
clobber. With this new standard, you might even get better
optimization as opposed to gcc's current interface as the compiler
will be able to do something more fine grain than the correct "memory"
clobber, and it will still have the correct behavior unlike the case
of no "memory" clobber.

AFAIK, it has been standardized to be implementable on all hardware
such that "you don't pay for what you don't use". Specifically, if you
write your data dependent loads correctly in the C source, your code
will work on the DEC-alpha, and you won't suffer any performance
penalties where it's not needed such as the x86.

In article <>,
Ian Collins <ian-> wrote:
>
>Just as we don't want C to be left behind. The C++ standard has adapted
>to modern hardware by incorporating threading into the core language and
>the C1x drafts do likewise.

If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.

One of the great benefits of modern hardware is protected memory. fork
gives you multiple threads of execution without throwing away that benefit.
To give up protected memory in the name of "adapting to modern hardware" is
ridiculous.

--
Alan Curry

On Jan 13, 12:32*pm, pac...@kosh.dhis.org (Alan Curry) wrote:
> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>
> One of the great benefits of modern hardware is protected memory. fork
> gives you multiple threads of execution without throwing away that benefit.
> To give up protected memory in the name of "adapting to modern hardware" is
> ridiculous.

Well, I think that's more to do with that not all operating systems
natively support a Posix-like fork - eg: win32, whereas all current
threading models are sufficiency similar to allow standardization.

If we're talking about a much more generic process spawn equivalent,
then I agree that would be nice to have. It would be nice for the
reasons you state, and it would be nice even if I was programming only
on unix-like systems to avoid the bugs in Posix fork.

Finally, see my other posts else-thread for other reasons which apply
to threads but don't apply to processes. Threading is inextricably
tied to code generation, so it really ought to be in the same standard
document that constrains the rest of the code generation of the
compiler, whereas the existence of and the use of processes don't
really constrain the code generation of a compiler.

(Alan Curry) writes:

> In article <>,
> Ian Collins <ian-> wrote:
>>
>>Just as we don't want C to be left behind. The C++ standard has adapted
>>to modern hardware by incorporating threading into the core language and
>>the C1x drafts do likewise.
>
> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.

Threads affect the language a lot more than fork() does. It's a
lot easier to add fork() as an afterthought than it is to add
threads.
--
Ben Pfaff
http://benpfaff.org

Alan Curry wrote:
> In article <>,
> Ian Collins <ian-> wrote:
>> Just as we don't want C to be left behind. The C++ standard has adapted
>> to modern hardware by incorporating threading into the core language and
>> the C1x drafts do likewise.
>
> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>
> One of the great benefits of modern hardware is protected memory.

C as well as C++ also operates on hardware that *does not have*
protected memory, though offers threads. The fork() primitive requires a
lot of support from the operating system, and support some (if not even
the majority of the operating systems I know) do not offer.

Greetings,
Thomas

On Thu, 13 Jan 2011, Ben Pfaff wrote:

> (Alan Curry) writes:
>
>> In article <>,
>> Ian Collins <ian-> wrote:
>>>
>>>Just as we don't want C to be left behind. The C++ standard has adapted
>>>to modern hardware by incorporating threading into the core language and
>>>the C1x drafts do likewise.
>>
>> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>
>Threads affect the language a lot more than fork() does. It's a
>lot easier to add fork() as an afterthought than it is to add
>threads.
>--
>Ben Pfaff
>http://benpfaff.org
>
Of course it is easy to add fork() on some platforms, but I think including
threads to the standard but fork() not would make fork() look like some 2nd
class threading, so people would always use threading instead of several
processes. Of course there are some scenarios were threads are actually better
than processes ( e.g. scientific calculations), but in most of the cases
processes with separated address spaces lead to programs much easier to debug and to maintain. Wouldn't it be possible to add a clone(2)-like library function where you can specify how much you want to share with your child process. You had to find a way how to support separated data on platforms without separated process memory, but couldn't you just handle per process data like a variable with prefix? (So if the programmer says "I want to have 2 processes, one containing var1 and one containig var2" you could simulate it by dividing your programs memory and only refer to the memory used by the simulated process you're in)
I have no experience with writing compilers or operating systems, so the
approach may be quite naive, but I would be glad to hear some feedback where I'm
wrong

On 01/14/11 10:48 AM, Tobias Blass wrote:
>
>
> On Thu, 13 Jan 2011, Ben Pfaff wrote:
>
>> (Alan Curry) writes:
>>
>>> In article<>,
>>> Ian Collins<ian-> wrote:
>>>>
>>>> Just as we don't want C to be left behind. The C++ standard has adapted
>>>> to modern hardware by incorporating threading into the core language and
>>>> the C1x drafts do likewise.
>>>
>>> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>>
>> Threads affect the language a lot more than fork() does. It's a
>> lot easier to add fork() as an afterthought than it is to add
>> threads.
>> --
>> Ben Pfaff
>> http://benpfaff.org
>>
> Of course it is easy to add fork() on some platforms, but I think including
> threads to the standard but fork() not would make fork() look like some 2nd
> class threading, so people would always use threading instead of several
> processes.

It's not a matter of 1st and 2nd class threading, it's a more matter of
code generation and optimisation, see Joshua Maurice's posts to this thread.

There's more to thread support than just creating threads.

--
Ian Collins

In article <>,
Ben Pfaff <> wrote:
> (Alan Curry) writes:
>
>> In article <>,
>> Ian Collins <ian-> wrote:
>>>
>>>Just as we don't want C to be left behind. The C++ standard has adapted
>>>to modern hardware by incorporating threading into the core language and
>>>the C1x drafts do likewise.
>>
>> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>
>Threads affect the language a lot more than fork() does. It's a
>lot easier to add fork() as an afterthought than it is to add
>threads.

In other words, threads with protected memory (i.e. fork) get along well
with the language, and threads without protected memory (i.e. pthread)
completely screw it up and force the programmer and the compiler to do
much more complicated things to compensate for the anything-goes shared
address space.

And this is an argument *for* non-protected-memory threads?

--
Alan Curry

On 01/14/11 11:22 AM, Alan Curry wrote:
> In article<>,
> Ben Pfaff<> wrote:
>> (Alan Curry) writes:
>>
>>> In article<>,
>>> Ian Collins<ian-> wrote:
>>>>
>>>> Just as we don't want C to be left behind. The C++ standard has adapted
>>>> to modern hardware by incorporating threading into the core language and
>>>> the C1x drafts do likewise.
>>>
>>> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>>
>> Threads affect the language a lot more than fork() does. It's a
>> lot easier to add fork() as an afterthought than it is to add
>> threads.
>
> In other words, threads with protected memory (i.e. fork) get along well
> with the language, and threads without protected memory (i.e. pthread)
> completely screw it up and force the programmer and the compiler to do
> much more complicated things to compensate for the anything-goes shared
> address space.
>
> And this is an argument *for* non-protected-memory threads?

Threads exist, get over it.

Some applications suit threads, some suit processes. Because process
don't required core language support they can be added purely as a
library extension.

Isn't it better to have the compiler do the complicated things rather
than force every programmer to do them?

--
Ian Collins

On 13 Jan., 15:32, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> jacob navia <ja...@spamsink.net> writes:
> > Le 13/01/11 13:42, tm a écrit :
> <snip>
> >> * - Support for closures (AFAIK gcc already supports them).
>
> AFAIK Apple has a version of gcc that does this, but it's not in gcc
> itself.

Ok. BTW, the proposed C++ support for closures looks
also interesting.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.