Rust

[Vitaly Davidovich]

I posed this question to this list a few years ago, but don’t recall much
participation - let’s try again :).

Has anyone moved their C, C++, Java, whatever low latency/high perf systems
(or components thereof) to Rust? If so, what type of system/component? What
has been your experience? Bonus points if you’re running this in production
:).
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37FLx5-4m9Bx%3DuLA3CWkk7JmqbUzRd5M0rSq2nk1XeR9rQ%40mail.gmail.com.

Re: purpose of an LFENCE

[Vitaly Davidovich]

FWIW, I’ve only seen lfence used precisely in the 2 cases mentioned in this
thread:
1) use of non-temporal loads (ie weak ordering, normal x86 guarantees go
out the window)
2) controlling execution of non-serializing instructions like rdtsc

I’d be curious myself to hear of other cases.

On Fri, Oct 4, 2019 at 10:10 AM Peter Veentjer 
wrote:

> I'm have been checking out the new fence API's in Java (Unsafe/VarHandle).
>
> I understand how the higher level API are translated to the logical
> fences. E.g. release fence -> LoadStore+StoreStore. There are some great
> post including
>
> https://shipilev.net/blog/2014/on-the-fence-with-dependencies/
> Great explanation how a release fence needs to be combined with a
> StoreLoad to preserve sequential consistency
>
> Also this post is great on the topic:
> https://preshing.com/20120913/acquire-and-release-semantics/
>
> When I zoom into hardware things are a bit more blurry.
>
> X86 provides the following guarantees:
> Loads won't be reordered with older loads   [LoadLoad]
> Stores won't be reordered with older stores (TSO) [StoreStore]
> Stores won't be reordered with older loads [LoadStore]
>
> One fundamental fence is the MFENCE because it will provide StoreLoad
> semantics. And on X86 the Unsafe.fullFence can be compiled to a MFENCE (in
> practice it uses the lock addl ...  but that isn't relevant for this
> discussion). This will prevent stores to be reordered with older stores and
> will make sure the memory is visible to other CPU's (by waiting for the
> store buffer to be drained).
>
I think you meant “prevent stores to be reordered with *later loads*”.  In
fact, awaiting store buffer drain is how it prevents the later load from
reordering with an earlier store - the load can’t retire (maybe not even
issue) while the store is sitting in the buffer (which would cause the
load-before-store reordering to be observed).

>
> The SFENCE was a bit more obscure to be because X86 proves TSO; so what is
> the point of adding a [StoreStore] fence is the platform provides it out of
> the box (so prevents stores to be reordered with older stores). Apparently
> there are certain instructions like those of SSE that are weakly ordered
> and these need to have this SFENCE. Ok. I can live with that.
>
> But the LFENCE I can't place. Initially I thought it would provide a
> similar fix as the SFENCE; so prevent load load reordering for weakly
> ordered instructions like those of SSE. But apparently the LFENCE is a very
> different beast.
>
> Could someone shed some light on the purpose of the LFENCE?
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/52527501-bffd-4a82-96fa-3fa618bec111%40googlegroups.com
> 
> .
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37EgmyMVW7p25ZejeM1EUiLoGTxExjVvjjeBG8KTzHAJ%2BA%40mail.gmail.com.

Re: Volatile semantic for failed/noop atomic operations

[Vitaly Davidovich]

On Sat, Oct 5, 2019 at 11:41 AM Steven Stewart-Gallus <
stevenselectronicm...@gmail.com> wrote:

> Couldn't you do a compare and compare and swap? With VarHandles something
> like
>
> if (ACTION.getOpaque(this) != expected) return false;
> return compareAndExchange(this, expected, newValue) == expected;
>
> Not sure I got this correct
>
In general you could.  This is sometimes referred to as TTAS (test and
test-and-set).

In this thread’s example, the “checks the count via a volatile load” I
mentioned is a similar effect; under some conditions, and opaque load might
be slightly cheaper than a volatile one (on x86 at least).  The difference
would only really be a result of the optimizer doing other scheduling
around the opaque load, but not around a volatile one.

The right/best approach for Simone’s case depends on specifics (don’t they
all?! :)).  I didn’t actually pick up on how often the termination protocol
triggers - I assumed it’s an uncommon/slow path.

>
>
> On Saturday, September 14, 2019 at 11:29:00 AM UTC-7, Vitaly Davidovich
> wrote:
>>
>> Unlike C++, where you can specify mem ordering for failure and success
>> separately, Java doesn’t allow that.  But, the mem ordering is the same for
>> failure/success there.  Unfortunately it doesn’t look like the javadocs
>> mention that, but I recall Doug Lea saying that’s the case on the
>> concurrency-interest mailing list (btw that’s probably the more appropriate
>> channel for this Java-centric question).
>>
>> For your case, it seems like an AtomicReference is more
>> appropriate.  terminate() sets it, then checks the count via a volatile
>> load (or maybe it can decrement() itself?); if zero, CAS null into the
>> action field to take/claim the action.  decrement() likewise tries to claim
>> the action via a CAS.  The snippet you have now would allow for concurrent
>> action execution, which is likely unsafe/wrong.
>>
>
>> On Fri, Sep 13, 2019 at 3:08 AM Simone Bordet 
>> wrote:
>>
>>> Hi,
>>>
>>> I have an atomic counter that gets incremented and decremented over
>>> time (non monotonically).
>>> At a certain point, I would like to enter a termination protocol where
>>> increments are not possible anymore and I set an action to run if/when
>>> the counter reaches zero.
>>> Trivial when using synchronized/lock, but I'd like to give it a try
>>> without them.
>>>
>>> class A {
>>>   private final AtomicLong counter;
>>>   // Non-volatile
>>>   private Runnable action;
>>>
>>>   void terminate(Runnable action) {
>>> this.action = action;
>>> // Volatile write needed here for visibility.
>>> if (counter.addAndGet(0) == 0) {
>>>   action.run();
>>> }
>>>   }
>>>
>>>   void decrement() {
>>> // Volatile read required to see this.action.
>>> if (counter.decrementAndGet() == 0) {
>>>   Runnable a = this.action;
>>>   if (a != null) {
>>> a.run()
>>>   }
>>> }
>>>   }
>>> }
>>>
>>> Is addAndGet(0) a volatile write? Can the write be optimized away?
>>> Similarly (although not relevant for this particular example), a
>>> _failed_ compareAndSet() has the semantic of a volatile write even if
>>> the set part was not done because the compare part failed?
>>>
>>> Thanks!
>>>
>>> --
>>> Simone Bordet
>>> ---
>>> Finally, no matter how good the architecture and design are,
>>> to deliver bug-free software with optimal performance and reliability,
>>> the implementation technique must be flawless.   Victoria Livschitz
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "mechanical-sympathy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mechanical-sympathy+unsubscr...@googlegroups.com.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msgid/mechanical-sympathy/CAFWmRJ3qGJ_qqrXmAHNDZ6ro01BQwe8czHZP7b-SoZ%2BrULhJAw%40mail.gmail.com
>>> .
>>>
>> --
>> Sent from my phone
>>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/43729dfa-1e73-4318-b446-e80c81422b6e%40googlegroups.com
> 
> .
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CAHjP37Fjb01ReqeVtj26JxT%2BKhhsVVRpZx7J-CpDXi_ZDpF7ow%40mail.gmail.com.