Re: RFC: C and concurrency (as CC extensions)
- From: Robbert Haarman <comp.lang.misc@xxxxxxxxxxxxx>
- Date: Sun, 9 Dec 2007 09:18:45 +0100
Since I don't have much experience with most of the technologies you
mentioned, I am just going to provide you with some general opinions.
First and foremost, I think C is an awful language for concurrent
programming. Almost everything you do alters state, from iterating over
the elements of an array with a for loop to large portions of the
standard library. The more altering state there is, the easier it is for
both developers and the compiler to introduce errors, _especially_ in
the face of concurrency.
Having said that, I do see some places where concurrency can be
introduced. Implicit parallelism can be introduced in places where the C
spec leaves results, and, in particular, evaluation order, unspecified.
Also, many of the imperative constructs in C (loops, in particular) can
actually be analyzed and parallelized in many cases. At least, Fortran
compilers do this and I would be highly surprised if the same
techniques wouldn't work in C.
As far as libraries go, obviously there is already support for
processes, threads, and various forms of message passing. All these are
platform-dependent, but libraries have been written that provide a
consistent API on multiple platforms (e.g. GLib provides threads on
win32 and *nix). Whole operating systems have been written with these,
and processes and sockets are pretty much the standard way to do
concurrency on *nix and Plan9.
If you are thinking about extending or breaking the language, I would
urge you to consider how much keeping all the ugliness and limitations
of C is really worth to you, and if you couldn't get that value by
designing a new, cleaner, better language that can call C code (e.g.
through embedding C code in your programs, through allowing extensions
to be written in C, or through allowing your language implementation to
be embedded in C programs).
If you decide that you do want to embrace and extend C, things I would
think about are slightly altering the semantics to allow more
concurrency, introducing some more abstract constructs (e.g. loops that
do not use visible state), constructs that allow programmers to specify
that some steps must be done without interruption (perhaps along the
lines of Promela's d_step or Java's synchronized), and constructs that
specify that the programmer does _not_ care about the order of
execution of some statements.
Otherwise, general good design principles apply. Try to avoid building
things into the compiler; instead, provide the building blocks to build
the things you want in libraries and build them there. For exmaple, many
common constructs in concurrent programming can be built out of others;
e.g. you can build monitors from mutexes (or the other way around). This
means you need to provide only one in your language, the other can be in
a library.
Regards,
Bob
--
On the other hand, you have different fingers.
.
- Prev by Date: Re: OT: efforts, emo crap...
- Next by Date: Need a 32-bit environment in which to test new language under Windows
- Previous by thread: Re: OT: efforts, emo crap...
- Next by thread: Re: RFC: C and concurrency (as CC extensions)
- Index(es):
Relevant Pages
|
