On 03/02/2014 11:02 AM, Michael Haberler wrote:
>
> Am 02.03.2014 um 15:21 schrieb John Kasunich <jmkasun...@fastmail.fm>:
>
> the problem is about passing _several scalar values between threads
> in an atomic fashion_ (transactional, meaning - all of them updated,
> or none of them updated as seen by the receiving thread).
>
> Is this what you are talking about? I think that is a very important
> property, and it is key to spell this out very clear. But a
> scheduling policy might not be the only solution to this problem, and
> not necessarily the best.
[From a non-sequential, later email:]
On 03/03/2014 05:16 PM, John Kasunich wrote:
> Can we agree that on a single core system, slow threads should never
> steal the CPU from fast threads, and web browsers should never steal
> the CPU from any "real-time" threads? Even if you are only doing
> simulated real-time?
Quick reality check: A scheduling system where slow threads never
preempt fast threads is unrelated to atomic transfer of multiple scalars
between threads, correct?
A simple copy into (clobber of) a couple of registers shared between
fast and slow threads is not atomic/transactional if a thread is
preempted while either reading or writing. That's a problem whether a
slow thread preempts a fast thread or the converse.
John
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
