"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).
>
standardized threading would be nice...
> 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.
>
ok.
well, possibly, using message passing, instead of memory access, could in
many cases speed up shared-memory as well. part of this could be that, for
example, data resides on particular systems, and in many cases it may be
faster simply to bounce a few messages back and forth, rather than have to
keep the memory consistent.
on single systems, this could help some, and on others (especially
network-based) this could help a lot more (message passing being a lot
cheaper then memory syncronization...).
as another issue, it is often needed to distinguish shared and non-shared
pointers/objects in such cases. as such, it would be useful to have a
'shared' keyword for pointers (and probably special alloc/free functions),
which would be essentially no-op for single-address-space systems.
of course, it may not be the place of the C standard to address clusters
and/or NUMA issues...
the alternative is simply requiring that the system be "made" to look like
a
shared-memory system, even if the arch is NUMA (but, this makes the
implementation, and keeping good performance, a lot more complicated, but
would avoid having to worry about local vs shared memory
objects/pointers...).
> 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.
I don't know of this article or the idea in particular.
what little I have found, makes me think it could be something
interesting.
personally, the Actor model could be nice, or Erlang style processes.
the problem with the latter though, would be comming up with a clean API
(passing buffers is possible, but API wise, not the cleanest possible
option).
eventually, I had still considered this (albeit, as a purely library
feature, making due with what is available...).
allowing non-trivial language extensions could also work (such as
first-class arg lists, ...), but IMO such drastic extensions are probably
better avoided.
|
