"Douglas A. Gwyn" <DAGwyn@[EMAIL PROTECTED]
> wrote in message
news:475D6A9D.7CEA5B05@[EMAIL PROTECTED]
> cr88192 wrote:
>> general opinions with regards to sup****ting concurrency within a C
>> compiler.
>
> This area is of course currently being developed by the C++
> Standards Working Group, with cooperation/participation of the
> C Standarfs Working Group. The likely outcome will be some
> form of threads (with shared memory).
>
> The hardest technical issues have to do with the memory model.
> It is not acceptable to require that shared memory be consistent
> at all times between separate threads, because that isn't how
> current multicore caching functions. A volatile-qualified
> access (and a sequence point) should suffice to flush out the
> cache location, but it seems that many architectures will have
> to flush an entire cache line at a time, which hurts performance.
>
> Instead of threads, some consideration should be given to using
> "channels", as described by Rob Pike in his Newsqueak article
> and implemented in Plan 9 (in C) and Limbo (in Inferno). This
> is close to the Hoare CSP model and is easier to work with.
found information.
yes, this seems an interesting way to handle concurrency in C...
fairly clean and elegant IMO.
possible syntax (as for syntax extensions):
'a<-' and '<-a' being syncronous.
a! for an async send (no async recieve, as this is semantically a lot more
problematic, rather, a function could be used to poll a channel).
declaration could be sort of like 'complex'.
int _Chan xi;
int chan xi; //macroed form
xi=mkchan();
xi<-3;
I opt for leaving out the '=', as this complicates the issue, and IMO adds
nothing cosmetically.
problem: ambiguous ('xi <- 3', vs: 'xi < -3', and adding '<-' as a token
would break conformance).
'<-=' could be regarded as a single operator.
also possible: 'xi<<3'.
xi!3; //would be an async send
this would imply that channels can buffer messages, or that something
similar to in the presentation is done 'behind the scenes' (personally, I
feel async sends are worth enough to justify syntax).
i=<-xi + <-xi
or:
i=<<xi + <<xi
'Alef' was also mentioned, and is interesting.
the 'tupple' type is interesting, and essentially similar to an idea I had
imagined (but too likely to have too strong of a language/implementation
impact though).
better may be to make due with direct struct passing.
typeder struct { float x, y; } A;
A chan xa;
A v;
xa<<v;
v=<<xa;
another possible feature could be allowing indirect struct
construction/destructuring:
v=(2, 3); //could be syntax sugarring for v=(A){2, 3};
(x, y)=v;
problem:
the former case, could be regarded as a semantics change, '(2, 3)'
becomming
a struct when in 'v=(2, 3);' v is a struct (vs interpreting '(2, 3)' as an
expression evaluating to '3'). this could potentially be regarded as a
standard violation though (maybe ok in this case, since cases like
'struct=int' are not valid anyways...).
'v={2, 3};' could also be a possible option though.
by extension:
xa<<(2, 3);
xa!(2, 3);
(x, y)=<<xa;
this feature might not be worthwhile though (would have an impact on
compiler internals...).
I would also think that a "pure" C library interface would make sense (all
of the above being possibly essentially just syntactic sugaring over said
library interface).
or such...
|
