[lock-free] SMRProxy POC

[Joseph Seigh]

The POC code is  here smrproxy  .   No 
plans to do any more work for the time being.

I was going to do a write up on this but it became too much of a hassle.  I 
spent more time trying to document it than I did writing the code in the 
first place.
There's a very brief treatment on a formal proof of correctness here 
.  
If I ever attempt this again, I will just draw the diagrams by hand and 
upload pictures of them to imbed in a document.   Minutes vs many many 
hours trying to get drawing apps to create what should be a simple diagram.

Joe Seigh

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/lock-free/e381367c-890a-4b04-8f12-0f39659c0a5an%40googlegroups.com.

Re: [lock-free] Linux membarrier syscall

[Joseph Seigh]

Well, apparently MIcrosoft doesn't actually fully support C11/C17 yet.  Not 
entirely sure why they are bothering at all since by the time they get 
around to it, the world and everyone else will have moved way beyond that.
I'm tempted to make a list of "Things That Will Happen Before Microsoft 
Supports C11/C17".   Flying cars is definitely on that list.

Joe Seigh

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/lock-free/63cff23b-d1f0-49a9-a525-7661157468b4n%40googlegroups.com.

Re: [lock-free] Linux membarrier syscall

[Joseph Seigh]

rseq?   The concept seems vaguely familiar. :)

Might not get past POC w/ smrproxy.  The idea was to write portable code 
using c11/c17 atomics  but I don't thing that's possible given how borked 
its memory model semantics are.  And I mean even more borked than their 
discussions of what they think the memory model problems are.  And I really 
don't feel like writing non portable inline assembly just to ensure the 
code is doing what it should be doing.

Joe Seigh 

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/lock-free/ae8349fc-a322-421f-8acd-9a8c4aa3a32an%40googlegroups.com.

Re: [lock-free] Linux membarrier syscall

[Joseph Seigh]

Ok, thanks.   I'll examine it in a bit more detail, though at first glance 
it looks like they're using ipi to speed things up by not having to wait 
for slower occurring kernel events.

I'm doing some work on  a hazard pointer based proxy collector w/ memory 
barriers that I suggested ages ago.  I posted some smrproxy timing 
comparisons 
<https://threadnought.wordpress.com/2023/06/09/smrproxy-timing-comparisons/>.  
I was going to rework the atomic reference counted proxy collector in 
c11/c17 atomics as well but the approximated timings are so bad compared to 
smrproxy that I think I will pass on that.

Joe Seigh

On Tuesday, June 13, 2023 at 3:03:34 AM UTC-4 Dmitry Vyukov wrote:

> On Fri, Jun 9, 2023 at 8:00 AM Joseph Seigh  wrote:
> >
> > Anyone know the difference between MEMBARRIER_CMD_PRIVATE_EXPEDITED and 
> MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE for membarrier.
> >
> > It would be nice if it actually does what I think it does. I really 
> don't want to have to read from procfs and do a lot of parsing and such.
>
> Nice to see you here again, Joe
>
> The docs are quite cryptic:
> "all its running threads siblings have executed a core serializing 
> instruction":
>
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/membarrier.h#L155
>
> In reality it does this:
>
> https://elixir.bootlin.com/linux/latest/source/kernel/sched/membarrier.c#L322
>
> https://elixir.bootlin.com/linux/latest/source/kernel/sched/membarrier.c#L184
>
> which boils down to:
>
> https://elixir.bootlin.com/linux/latest/source/arch/x86/include/asm/sync_core.h#L42
>
> * This function forces the icache and prefetched instruction stream to
> * catch up with reality in two very specific cases:
> *
> * a) Text was modified using one virtual address and is about to be 
> executed
> * from the same physical page at a different virtual address.
> *
> * b) Text was modified on a different CPU, may subsequently be
> * executed on this CPU, and you want to make sure the new version
> * gets executed. This generally means you're calling this in an IPI.
>
>
> So it looks like it's intended for self-modifying code...
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/lock-free/02316b45-8d28-49f3-af60-c49ae27518ban%40googlegroups.com.

[lock-free] Linux membarrier syscall

[Joseph Seigh]

Anyone know the difference between MEMBARRIER_CMD_PRIVATE_EXPEDITED 
and MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE for membarrier.

It would be nice if it actually does what I think it does.   I really don't 
want to have to read from procfs and do a lot of parsing and such.

Joe Seigh

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/lock-free/f3e7343e-ccff-45e4-a881-c12c69948a6bn%40googlegroups.com.