Re: [lock-free] One reason why I like atomic_thread_fence...

On Saturday, April 7, 2018 at 1:46:20 AM UTC-7, Dmitry Vyukov wrote: > > On Thu, Apr 5, 2018 at 10:03 PM, Chris M. Thomasson <cri...@charter.net > > wrote: > > On Tuesday, April 3, 2018 at 5:44:38 AM UTC-7, Dmitry Vyukov wrote: > >> > >> On Sat, Mar 3

Re: [lock-free] One reason why I like atomic_thread_fence...

On Friday, April 13, 2018 at 11:45:51 PM UTC-7, Dmitry Vyukov wrote: > > On Mon, Apr 9, 2018 at 3:38 AM, Chris M. Thomasson <cri...@charter.net > > wrote: > > On Saturday, April 7, 2018 at 1:46:20 AM UTC-7, Dmitry Vyukov wrote: > >> > >> On Thu, Apr

Re: [lock-free] One reason why I like atomic_thread_fence...

On Friday, April 20, 2018 at 2:06:22 AM UTC-7, Dmitry Vyukov wrote: > > On Mon, Apr 16, 2018 at 12:32 AM, Chris M. Thomasson > <cri...@charter.net > wrote: > > > > > > On Friday, April 13, 2018 at 11:45:51 PM UTC-7, Dmitry Vyukov wrote: > >> &g

[lock-free] Re: Simple DWCAS based Proxy Collector, refined... ;^)

Fwiw, the following is some C++11 code that should compile and run fine on systems that support lock-free DWCAS. I like the Relacy code because it helps make sure everything is Kosher. And, I like the C++11 code because it is an example of a real implementation. Anyway, here is the code:

[lock-free] One reason why I like atomic_thread_fence...

Notice how there is an acquire barrier inside of the CAS loop within the enqueue and dequeue functions of: http://www.1024cores.net/home/lock-free-algorithms/queues/bounded-mpmc-queue ? Well, fwiw we can get rid of them by using stand alone fences: Btw, sorry for the membar abstraction.

Re: [lock-free] Simple DWCAS based Proxy Collector, refined... ;^)

On Wednesday, March 28, 2018 at 11:20:58 PM UTC-7, Dmitry Vyukov wrote: > > On Tue, Mar 27, 2018 at 11:23 PM, Chris M. Thomasson > <cri...@charter.net > wrote: > > > Fwiw Dmitry, I have been working with fractals a lot lately, and was > > > wondering if I coul

Re: [lock-free] Simple DWCAS based Proxy Collector, refined... ;^)

On Wednesday, March 28, 2018 at 11:20:58 PM UTC-7, Dmitry Vyukov wrote: > > On Tue, Mar 27, 2018 at 11:23 PM, Chris M. Thomasson > <cri...@charter.net > wrote: > > Fwiw Dmitry, I have been working with fractals a lot lately, and was > > wondering if I could stil

[lock-free] Simple DWCAS based Proxy Collector, refined... ;^)

Fwiw Dmitry , I have been working with fractals a lot lately, and was wondering if I could still program a proxy collector from scratch. Remember my old collector here: http://webpages.charter.net/appcore/misc/pc_sample_h_v1.html ? You are using

Re: [lock-free] Re: Simple Example, Very Basic Per-Thread Proxy GC...

On Saturday, December 22, 2018 at 11:53:07 PM UTC-8, Dmitry Vyukov wrote: > > On Thu, Dec 20, 2018 at 12:17 AM Chris M. Thomasson > wrote: > > > > On Wednesday, December 19, 2018 at 2:02:31 AM UTC-8, Dmitry Vyukov > wrote: > >> > >> On Wed,

[lock-free] Re: Eventcount with timeout

On Sunday, December 23, 2018 at 9:30:03 PM UTC-8, Artur Brugeman wrote: > > Hi Dmitry, > > I want to use your eventcount (took the source from intel forum). > > Currently I was using semaphores, which allowed me to set waiting timeout. > > Questions: > 1. Is the source from intel forum 'the

[lock-free] Re: Atomic XCHG based Stack, simple for learning...

On Friday, December 28, 2018 at 10:38:50 PM UTC-8, Chris M. Thomasson wrote: > > This experimental algorithm uses only XCHG at the cost of having a > consumer wait for the next pointer to be set in a node. However, it allows > for real work to be done before any waits are p

[lock-free] Simple Example, Very Basic Per-Thread Proxy GC...

If interested, I can give more details. For now, here is the code in the form of a Relacy Test Unit: https://pastebin.com/raw/FpnvTqvM (raw link, no ads! :^) ___ // Simple Per-Thread Mutex Based Proxy Collector // For Academic and Experimental things... // Beginner,

Re: [lock-free] Re: Simple Example, Very Basic Per-Thread Proxy GC...

On Wednesday, December 19, 2018 at 3:17:18 PM UTC-8, Chris M. Thomasson wrote: > > On Wednesday, December 19, 2018 at 2:02:31 AM UTC-8, Dmitry Vyukov wrote: >> >> On Wed, Dec 19, 2018 at 7:05 AM Chris M. Thomasson >> wrote: >> > >> > On Monday, Decem

Re: [lock-free] Re: Simple Example, Very Basic Per-Thread Proxy GC...

On Thursday, December 20, 2018 at 3:03:05 PM UTC-8, Chris M. Thomasson wrote: > > On Wednesday, December 19, 2018 at 3:17:18 PM UTC-8, Chris M. Thomasson > wrote: >> >> On Wednesday, December 19, 2018 at 2:02:31 AM UTC-8, Dmitry Vyukov wrote: >>> >>>

[lock-free] Re: wait-free combiner lock

Need to check this out. Thanks for the heads up. On Friday, November 9, 2018 at 4:13:13 PM UTC-8, Dmitry Vyukov wrote: > > Hi, > > An interesting wait-free combiner lock with 2 XCHG to enqueue work: > https://github.com/romkatv/action-chain/blob/master/src/action_chain.h > > This is somewhat

[lock-free] Re: Eventcount with timeout

can fail the try_lock a couple of times, then just lock the sucker! ;^) > > > On Friday, December 28, 2018 at 4:32:04 AM UTC+5, Chris M. Thomasson wrote: >> >> On Sunday, December 23, 2018 at 9:30:03 PM UTC-8, Artur Brugeman wrote: >>> >>> Hi Dmitry, >>>

[lock-free] Atomic XCHG based Stack, simple for learning...

This experimental algorithm uses only XCHG at the cost of having a consumer wait for the next pointer to be set in a node. However, it allows for real work to be done before any waits are performed. So, the "real" work should provide a "natural backoff" that might minimize the waiting. The

Re: [lock-free] Re: Simple Example, Very Basic Per-Thread Proxy GC...

On Wednesday, December 19, 2018 at 2:02:31 AM UTC-8, Dmitry Vyukov wrote: > > On Wed, Dec 19, 2018 at 7:05 AM Chris M. Thomasson > wrote: > > > > On Monday, December 17, 2018 at 11:23:20 PM UTC-8, Chris M. Thomasson > wrote: > >> > >> If interest

[lock-free] Re: Simple Example, Very Basic Per-Thread Proxy GC...

On Monday, December 17, 2018 at 11:23:20 PM UTC-8, Chris M. Thomasson wrote: > > If interested, I can give more details. For now, here is the code in the > form of a Relacy Test Unit: > > https://pastebin.com/raw/FpnvTqvM >

[lock-free] Re: Experimental Read/Write Mutex..

quot; test, in Relacy... // By: Chris M. Thomasson //___ //#define RL_DEBUGBREAK_ON_ASSERT //#define RL_MSVC_OUTPUT //#define RL_FORCE_SEQ_CST //#define RL_GC #include #include // Simple macro based redirection of the verbose std membars. #define CT_

[lock-free] Re: Experimental Read/Write Mutex..

On Friday, March 1, 2019 at 7:11:20 AM UTC-8, Manuel Pöter wrote: > > I could get my hands on an AMD EPYC 7351P system and a Xeon Phi (Knights > Corner) if you are interested in more results... > I would be grateful if you can find the time to do this Manuel: Thanks. :^) Really like the

[lock-free] Re: Experimental Read/Write Mutex..

I need to create another type of test, one that does not hammer things so much wrt creating an equal amount of reader and writer threads. I need to basically model a "read-mostly" work environment. Instead of a hyper-hardcore read and write focused contention massacre... -- --- You received

Re: [lock-free] Experimental Read/Write Mutex..

On Sunday, March 3, 2019 at 1:28:03 AM UTC-8, Chris M. Thomasson wrote: > > On Tuesday, February 26, 2019 at 12:16:24 AM UTC-8, Dmitry Vyukov wrote: >> >> On Wed, Feb 20, 2019 at 1:31 AM Chris M. Thomasson >> wrote: >> [...] >> We can try with some new cha

[lock-free] Re: Experimental Read/Write Mutex..

On Saturday, March 2, 2019 at 7:28:28 AM UTC-8, Manuel Pöter wrote: > > > > On Friday, 1 March 2019 23:29:41 UTC+1, Chris M. Thomasson wrote: >> >> On Friday, March 1, 2019 at 7:11:20 AM UTC-8, Manuel Pöter wrote: >>> >>> I could get my hands on an AMD

[lock-free] Re: TensorFlow scheduler

On Tuesday, March 5, 2019 at 10:04:40 PM UTC-8, Chris M. Thomasson wrote: > > > > On Wednesday, February 27, 2019 at 1:35:04 AM UTC-8, Dmitry Vyukov wrote: >> >> Hi, >> >> TensorFlow CPU task scheduler I wrote some time ago: >> &

[lock-free] Re: Experimental Read/Write Mutex..

On Wednesday, February 27, 2019 at 6:34:41 AM UTC-8, Manuel Pöter wrote: > > Benchmarked this on 2 systems with `THREADS` set to 1, 2 and 4. > > Result 1: > > 8x Intel(R) Xeon(R) CPU E7- 8850 @ 2.00GHz (80 cores, 2x SMT) > > Testing Version 0.1: Chris M. Thomasson's Experimental Read/Write Mutex

Re: [lock-free] Experimental Read/Write Mutex..

On Tuesday, February 26, 2019 at 12:16:24 AM UTC-8, Dmitry Vyukov wrote: > > On Wed, Feb 20, 2019 at 1:31 AM Chris M. Thomasson > wrote: > [...] > We can try with some new change :) > Just as a first start, I changed m_count to unsigned long, and is "integrate

Re: [lock-free] Re: TensorFlow scheduler

On Thursday, March 7, 2019 at 2:59:51 PM UTC-8, Chris M. Thomasson wrote: > > On Wednesday, March 6, 2019 at 9:56:54 PM UTC-8, Dmitry Vyukov wrote: >> >> On Wed, Mar 6, 2019 at 7:11 AM Chris M. Thomasson >> wrote: >> >>> >> >>> Hi, >

Re: [lock-free] Re: TensorFlow scheduler

On Wednesday, March 6, 2019 at 9:56:54 PM UTC-8, Dmitry Vyukov wrote: > > On Wed, Mar 6, 2019 at 7:11 AM Chris M. Thomasson > wrote: > >>> > >>> Hi, > >>> > >>> TensorFlow CPU task scheduler I wrote some time ag

[lock-free] Re: Experimental Read/Write Mutex..

Sorry for not working on this like I should be doing. Fwiw, I got distracted because several of my fractals are now on a very nice site: http://paulbourke.net/fractals My work: http://paulbourke.net/fractals/logspiral http://paulbourke.net/fractals/multijulia

[lock-free] Experimental Read/Write Mutex..

. If not defined then it will test against std::shared_mutex. I am wondering if anybody can compile and run the code? Test it out on as many operating systems as you can. Can you please show the output? Thanks everybody. :^) Here is the code: /* Simple, crude read/write mutex test by: Chris M

Re: [lock-free] Experimental Read/Write Mutex..

On Saturday, February 16, 2019 at 11:24:42 PM UTC-8, Dmitry Vyukov wrote: > > On Sun, Feb 17, 2019 at 12:34 AM Chris M. Thomasson > wrote: > > > > Fwiw, here is a simple benchmark for an older read/write algorithm I > invented: > > > > &

Re: [lock-free] Experimental Read/Write Mutex..

On Sunday, February 17, 2019 at 2:51:04 PM UTC-8, Chris M. Thomasson wrote: > > On Saturday, February 16, 2019 at 11:24:42 PM UTC-8, Dmitry Vyukov wrote: >> >> On Sun, Feb 17, 2019 at 12:34 AM Chris M. Thomasson >> wrote: > > > [...] >> > T

[lock-free] Re: Experimental Read/Write Mutex..

amount of time. by: Chris M. Thomasson __*/ #include #include #include #include #include #include #include #include #include #include #include #include #include // undefine to test std::shared_mutex #define

[lock-free] Re: Experimental Read/Write Mutex..

On Monday, February 18, 2019 at 8:50:21 PM UTC-8, Chris M. Thomasson wrote: > > Fwiw, here is a more realistic benchmark, in the Relacy stage for > verification purposes: > > https://pastebin.com/raw/j4wrg050 > > Fwiw, I have almost completed my new benchmark in pure C++11

Re: [lock-free] Experimental Read/Write Mutex..

On Monday, February 18, 2019 at 12:13:21 PM UTC-8, Dmitry Vyukov wrote: > > On Sun, Feb 17, 2019 at 11:51 PM Chris M. Thomasson > wrote: > > > > On Saturday, February 16, 2019 at 11:24:42 PM UTC-8, Dmitry Vyukov > wrote: > >> > >> On Sun, Feb 17, 201

[lock-free] Re: Abseil/nsync Mutex

On Wednesday, February 20, 2019 at 12:59:28 AM UTC-8, Dmitry Vyukov wrote: > > Hi, > > FYI, if you haven't seen this yet: > > https://github.com/abseil/abseil-cpp/blob/master/absl/synchronization/mutex.h > > https://github.com/abseil/abseil-cpp/blob/master/absl/synchronization/mutex.cc > > >

[lock-free] crude read/write benchmark code...

Fwiw, I wrote a crude new benchmark that measures how many reads and writes can be performed in a given amount of time. My algorithm vs std::shared_mutex. So, we are _primarily_ looking for how many reads can be performed in this test at 60 seconds. The number of threads is variable and is