- "C++20: The Advantages of Modules" by Rainer Grimm - 2 Updates
- Mutex with Spin-Count - 16 Updates
- neoGFX animation is as simple as... - 4 Updates
- 944 FPS - 1 Update
- Recursive spinlock - 2 Updates
| Melzzzzz <Melzzzzz@zzzzz.com>: May 13 02:04AM > coroutines, and modules. Modules promise a lot: compile-time > improvement, isolation of macros, the abolition of header files, and > ugly workarounds." How they think to implement modules? In this article nothing to be seen... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 13 03:32PM +0200 On 13.05.2020 04:04, Melzzzzz wrote: >> ugly workarounds." > How they think to implement modules? In this article nothing to be > seen... Visual C++ has for several versions had experimental support for modules. So you can try it out. I haven't tried it though. - Alf |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 04:36PM -0700 I finally implemented the Windows version of the mutex using a Relacy test unit. It works fine. However, the POSIX version needs to properly handle sem_wait return values wrt errno, Relacy simulates this and will report a deadlock. I omitted all of the spin counting code you had and just stuck to the main lock logic. Take a look at the code and make sure I got everything right. Pretty sure I did. I had to add a destructor to the Semaphore class to close the handle. Relacy reports a memory leak if this is not accomplished. Btw, the semaphore logic you use i the mutex itself is basically the same as a benaphore: https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26 Fwiw, here is the test code: /* Mutex with Spin Count Algorithm by Bonita Test by Chris M. Thomasson _____________________________________________________*/ //#define RL_DEBUGBREAK_ON_ASSERT //#define RL_MSVC_OUTPUT //#define RL_FORCE_SEQ_CST //#define RL_GC #include <relacy/relacy_std.hpp> #include <iostream> #include <vector> #include <algorithm> #define CT_THREADS 3 struct Semaphore { Semaphore(); ~Semaphore(); // dtor void release(); void wait(); private: HANDLE hSem; }; Semaphore::Semaphore() : hSem(CreateSemaphore(nullptr, 0, 0x7FFFFFFF, nullptr)) {} Semaphore::~Semaphore() { CloseHandle(hSem); } void Semaphore::release() { ReleaseSemaphore(hSem, 1, nullptr); } void Semaphore::wait() { WaitForSingleObject(hSem, INFINITE); } struct SpinMutex { std::atomic<unsigned long> lockCounter; unsigned long spinCount; Semaphore sem; SpinMutex(unsigned long spincount) : lockCounter(0), spinCount(spincount) {} void lock() { for (unsigned long sc = spinCount; sc; --sc) { unsigned long cmp = 0; if (lockCounter.compare_exchange_weak( cmp, 1, std::memory_order_acquire )) { return; } } if (lockCounter.fetch_add(1, std::memory_order_acquire) != 0) { // slow path sem.wait(); } } void unlock() { if (lockCounter.fetch_sub(1, std::memory_order_release) != 1) { // slow path sem.release(); } } }; struct ct_experiment : rl::test_suite<ct_experiment, CT_THREADS> { SpinMutex g_lock; VAR_T(unsigned long) g_state; ct_experiment() : g_lock(7), g_state(0) {} void thread(unsigned int tidx) { //std::cout << "thread: " << tidx << "\n"; g_lock.lock(); VAR(g_state) += 1; g_lock.unlock(); } }; // Test away... Or fly? Humm... int main() { { rl::test_params p; p.iteration_count = 10000000; //p.execution_depth_limit = 33333; //p.search_type = rl::sched_bound; //p.search_type = rl::fair_full_search_scheduler_type; //p.search_type = rl::fair_context_bound_scheduler_type; rl::simulate<ct_experiment>(p); } return 0; } |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:08AM +0200 > Fwiw, this is a bug. You are misusing sem_wait. ... No. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:09AM +0200 > I should say that sem_wait returns -1 and errno can be EINTR. That's experimental code. EINTR normally doesn't happen. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:14AM +0200 > I finally implemented the Windows version of the mutex using a Relacy > test unit. It works fine. However, the POSIX version needs to properly > handle sem_wait return values wrt errno, Boy, you're so strupid. That's not industrial-level code for relase to a product; so there's no need to handle EINTR. > I had to add a destructor to the Semaphore class to close the handle. Also not necessary for the purpose of this code, that's while I skipped it. |
| red floyd <no.spam.here@its.invalid>: May 12 11:15PM -0700 On 5/12/2020 11:14 PM, Bonita Montero wrote: >> I had to add a destructor to the Semaphore class to close the handle. > Also not necessary for the purpose of this code, that's while I skipped > it. So anyone who disagrees with you is stupid. Bye bye... *PLONK* |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:17AM +0200 >> Also not necessary for the purpose of this code, that's while I skipped >> it. > So anyone who disagrees with you is stupid. Bye bye... *PLONK* His objections simply have nothing to do with the question discussed, i.e. whether adaptive mutexes make sense. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 11:18PM -0700 On 5/12/2020 11:09 PM, Bonita Montero wrote: >> I should say that sem_wait returns -1 and errno can be EINTR. > That's experimental code. EINTR normally doesn't happen. lol. Okay... Whatever. Anyway, your code works in a Relacy test unit. :^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 11:19PM -0700 On 5/12/2020 11:18 PM, Chris M. Thomasson wrote: >>> I should say that sem_wait returns -1 and errno can be EINTR. >> That's experimental code. EINTR normally doesn't happen. > lol. Okay... Whatever. Anyway, your code works in a Relacy test unit. :^) The test unit makes me have to add the dtor to your code. Also, it makes me have to make your code handle EINTR from sem_wait. It actually simulates that. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 11:19PM -0700 On 5/12/2020 11:08 PM, Bonita Montero wrote: >> Fwiw, this is a bug. You are misusing sem_wait. ... > No. Yes. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:20AM +0200 > lol. Okay... Whatever. Anyway, your code works in a Relacy test unit. :^) Sorry, there's no need for Relacy here because the mutex is simple. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 11:21PM -0700 On 5/12/2020 11:17 PM, Bonita Montero wrote: >> So anyone who disagrees with you is stupid. Bye bye... *PLONK* > His objections simply have nothing to do with the question discussed, > i.e. whether adaptive mutexes make sense. Porting your code over to Relacy makes these corrections necessary to pass a test. You failed to close the handle to the semaphore, and failed to handle EINTR. Well, shi% happens. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 11:21PM -0700 On 5/12/2020 11:20 PM, Bonita Montero wrote: >> lol. Okay... Whatever. Anyway, your code works in a Relacy test unit. :^) > Sorry, there's no need for Relacy here because the mutex is simple. It found a memory leak and a dead lock condition wrt EINTR. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:27AM +0200 > Porting your code over to Relacy makes these corrections necessary to > pass a test. It wasn't my idea to add Relacy-code here. The code is trivial and you can see withoud debugging that it is correct for the discussed purpose. that you use this tool here makes me strongly doubt you. > You failed to close the handle to the semaphore, and failed > to handle EINTR. ... I didn't think about EINTR but that doesn't matter in this case. And the other was intenionally. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:29AM +0200 >> Sorry, there's no need for Relacy here because the mutex is simple. > It found a memory leak and a dead lock condition wrt EINTR. You're such a mega-idiot. That's not industrial-level code, it's expermental to allow to prove Öö Tiibs assumptions. And for this puprose it is completely adequate. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 09:10AM +0200 So everything is fine now: #if defined(_MSC_VER) #define _CRT_SECURE_NO_WARNINGS #include <Windows.h> #pragma warning(disable: 6031) #pragma warning(disable: 6387) #pragma warning(disable: 26495) #elif defined(__unix__) #include <semaphore.h> 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment