Proposal: provide cas and barriers symbols even without -threaded
Ryan Newton
rrnewton at gmail.com
Thu Aug 1 18:32:00 CEST 2013
On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:
> ok, could you add those comments (about additional operations to consider)
> to the ticket?
>
Sure. Just did that.
> relatedly: if we want these atomic ops to use the sequential analogues
> when we're not using the threaded run time system, does that mean
> we need to have a symbol / constant variable exposed in the RTS we link
> in, so that the inline code branches on a linktime constant value / symbol
> (something like "isThreadedRTS:: Bool", ) or some sort of analogue
> thereof?
>
I think it will take some care to mimic the semantics perfectly. Why not
just leave the real atomic ops even in non-threaded mode, at least at
first? Later we can optimize it if we find that people are using
concurrent data structures heavily in non-threaded mode ;-).
> one nice thing about doing such, is that if at some point link time
> optimization is added, the branch would go away! On the other hand, it
> could be argued that the cost of the call to the CAS primops in their
> current form isn't that much more expensive than such a branch.
>
Indeed, I'm much more concerned about performance in the threaded case and
making sure they're correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130801/1abc062c/attachment.htm>
More information about the ghc-devs
mailing list