profile
viewpoint
Dix Lorenz dixlorenz mediMACH GmbH & Co KG Norderstedt, Germany

eatingtomatoes/pure_simd 176

A simple, extensible, portable, efficient and header-only SIMD library!

dixlorenz/compute 0

A C++ GPU Computing Library for OpenCL

dixlorenz/cppformat 0

Small, safe and fast formatting library for C++

dixlorenz/fiber 0

userland threads

dixlorenz/libraries 0

ASL libraries will be migrated here in the stlab namespace, new libraries will be created here.

dixlorenz/pure_simd 0

A simple, extensible, portable, efficient and header-only SIMD library!

push eventdixlorenz/TournamentManager

Dix Lorenz

commit sha daabfbece9db4a1c8a852fa712444bb9b8007710

cli app

view details

push time in 5 days

startedgao-sun/eul

started time in 6 days

push eventdixlorenz/TournamentManager

Dix Lorenz

commit sha cf96894f68c4704943eddc941cffddabeee118c6

support dark stations

view details

push time in 8 days

push eventdixlorenz/TournamentManager

Dix Lorenz

commit sha 76a5dcd0c12fc43f167b718f7e37b817df4f2bce

make a schedule

view details

push time in 9 days

push eventdixlorenz/TournamentManager

Dix Lorenz

commit sha ae8d45d496f14f09c45284ee47e868c8dae5ce95

playing around

view details

push time in 14 days

create barnchdixlorenz/TournamentManager

branch : main

created branch time in 15 days

created repositorydixlorenz/TournamentManager

created time in 15 days

startedTheLartians/ModernCppStarter

started time in a month

startedDavid-Haim/concurrencpp

started time in 2 months

issue openedboostorg/fiber

reproducible bug in spinlock_ttas

I managed to reproduce the hang I got in #254 :

int main(int /*argc*/, const char * /*argv*/ [])
{
   struct Item {
      int value{};
      Item(int v = 0) : value(v) {}
      Item(Item &&item)
      {
         boost::this_fiber::yield(); 
         value = item.value;
      }
      Item &operator=(Item &&item)
      {
         boost::this_fiber::yield();
         value = item.value;
         return *this;
      }
   };
   
   std::size_t channel_cap = 32;
   std::size_t producer_count = std::thread::hardware_concurrency();
   int max_value = 100;

   std::vector<std::thread>              threads;
   boost::fibers::buffered_channel<Item> channel(channel_cap);

   boost::fibers::barrier b(producer_count + 1);

   boost::fibers::fiber f_pop;

   unsigned sum = 0;

   for (unsigned i = 0; i < producer_count; ++i) {

      threads.emplace_back([&, i] {
         if (i == 0) {
            f_pop = boost::fibers::fiber([&] {
               {
                  Item x{};
                  while (boost::fibers::channel_op_status::success == channel.pop(x)) {
                     sum += x.value;
                  }
               }
            });
         }
         boost::fibers::fiber f([&] {
            for (int x = 0; x < max_value; ++x)
               channel.push(Item{ x });
         });
         f.join();
         b.wait();
         if (i == 0)
            f_pop.join();
      });
   }

   b.wait();
   channel.close();

   for (auto &t : threads)
      t.join();
      
   std::cout << sum << std::endl;

Obviously I am not really yielding the fiber in the move constructor/assignment, but when using buffered_channel::pop in a loop like this (which is perfectly reasonable) these get called; in my case the "previous" item returned an internal resource into a pool which was protected by a mutex which might yield the fiber and at that moment the channel is locked.

I think this could be fixed by spinlock_ttas::lock yielding this_fiber and not this_thread; I can't test that, this_fiber is not available in spinlock_ttas.hpp, I don't know how to yield the current fiber with the operations available in that header.

Technically it could probably also be solved in buffered_channel::pop(), but that would get really ugly.

At the very least this needs a warning in the documentation.

created time in 2 months

issue commentboostorg/fiber

bug in buffered_channels/spinlock_ttas::lock?

I spoke too soon, my code still hangs, just more rarely.

Unfortunately I haven't been able to reproduce it in a small code sample; I can't even reproduce it on all the machines I have available, only on the one with the fewest CPUs (4 + HT). I am using the regular round-robin scheduler and I have one thread per CPU Core. Each of those threads has (among others, but those should be dormant) one fiber pushing items onto a buffered_channel; one thread also has a fiber popping items. Sometimes it hangs, all threads are stuck in spinlock_ttas::lock(), after my fix now in line 78, std::this_thread::yield(). I have only witnessed the hang with very high contention where the actual processing behind the items was very short.

The only explanation I have is that the one fiber that has the lock is not active atm and this_thread::yield() doesn't cycle through available fibers. But that would mean that the fiber owning the lock has switched out and I don't see any code in buffered_channel::push or buffered_channel::pop that activates another context without also releasing the lock (but then, "std::memory_order_release" et al are way outside of my comfort zone). I've seen the hang with a full channel or an almost empty channel. There is no closing of the channel or anything, it hangs sometimes in the middle.

I am still trying to get a reproducible case, but I am reasonably sure that there is a bug hidden somewhere buffered_channel::push, buffered_channel::pop and spinlock_ttas::lock.

dixlorenz

comment created time in 2 months

issue commentboostorg/fiber

bug in buffered_channels/spinlock_ttas::lock?

I added a pull request (#255) to increase the variable; my problem does not occur anymore

dixlorenz

comment created time in 2 months

PR opened boostorg/fiber

increase retries on all paths through the loop
+1 -0

0 comment

1 changed file

pr created time in 2 months

create barnchdixlorenz/fiber

branch : spinlock_retries

created branch time in 2 months

fork dixlorenz/fiber

userland threads

fork in 2 months

issue openedboostorg/fiber

bug in buffered_channels/spinlock_ttas::lock?

I have quite a few fibers pushing items rapidly on a buffered_channel and every so often the program hangs with all cores being busy. They are all stuck at pushing into the channel, getting the lock, namely at

std::this_thread::sleep_for( us0);

That branch never increases the variable "retries", so it never gets to the third branch of the locking loop (where it would yield). I am pretty sure that is a bug.

But also: why are both of these branches sleeping/yielding this_thread? Shouldn't they be sleeping/yielding this_fiber? I am unsure about this one, but as far as I understand it should give other fibers on the same thread the chance to release the lock.

created time in 2 months

push eventdixlorenz/cppformat

Greg Sjaardema

commit sha 34b3f7b7aa5570cd40a91d96e2203c8b13a3b7cb

Avoid windows issue with min() max() macros Including the ``windows.h`` file without defining ``NOMINMAX`` will define the `min()` and `max()` macros which will result in issues compiling any C++ code that uses any variant of `max`, for example `std::numeric_limits<std::streamsize>::max()` and many others. Although max() isn't used in Fmt anywhere, it is often used in codes that include a format include file so simply upgrading to the current version of lib::fmt will break the windows build which worked prior to the update...

view details

Victor Zverovich

commit sha 4999796c15b62b9992feec780a3fcf11cfc33afd

Fix the docs

view details

Victor Zverovich

commit sha 63b23e786aae3cdf31e5a79c658facba8f45a158

Merge branch 'master' of github.com:fmtlib/fmt

view details

Victor Zverovich

commit sha 7d01859ef16e6b65bc023ad8bebfedecb088bf81

Fix handling of unsigned char strings in printf

view details

Victor Zverovich

commit sha 3860edc5d9e7e9a7431d30b7f98cbb206688d0a5

Bump version

view details

Victor Zverovich

commit sha 141a00d642a6ce2108ba8ce0425301ea8b0fe70b

Define FMT_EXTERN_TEMPLATE_API on export

view details

Victor Zverovich

commit sha 36ea32640fecc775d16fd337c447762bede3eac1

Suppress a bogus MSVC warning

view details

Victor Zverovich

commit sha bbb6b357c7f5f92b883dfd5d97065e76bcce8132

Add floating-point L specifier (#1624)

view details

Victor Zverovich

commit sha 8cd8ef03eb27c1b7285b9a9904eb7b514ed5cf22

Simplify warning suppression

view details

Victor Zverovich

commit sha e30d8391e401f74a48d822c64d96f965ff16c722

Suppress an MSVC warning (#1622)

view details

Victor Zverovich

commit sha 7645ca072480a374cb467907fd29a92f9a1287a7

Clean up printf

view details

Victor Zverovich

commit sha 3aab2171edd265ca12c2248507ecd1d9832eb465

Clean up basic_format_args

view details

gabime

commit sha 7404e33a73aa1d0b07d733bff98f6863d2db46a5

Fix clang warning about explicit ctor

view details

gabime

commit sha 3cd5179f32512ab07d66bd5d0e80aa4da9de627c

Fixed clang tidy warning -multiple declarations in a single statement reduces readability

view details

Victor Zverovich

commit sha e99809f29da1002e8b9246e9278084ad231174e5

Fix ostream support in sprintf (#1631)

view details

Victor Zverovich

commit sha 07b4c246ea033492c2d291b3335381c630487b21

Fix a typo

view details

Victor Zverovich

commit sha 5899267c47c12ce0be664d913440fd9be50f20b3

Fix a clang-tidy warning

view details

Victor Zverovich

commit sha fdcf7870a2e5b543144cf38aceec85c3d05d8dff

Add stack-based named argument storage

view details

Dmitriy Kurkin

commit sha a9d62d3f354cb598b809ead32ef39e23e854d2f1

Add check for CompiledFormat to avoid ambiguous call

view details

Victor Zverovich

commit sha 8a4630686e2dd24900897298c4ae1362de749ed8

Improve handling of named arguments

view details

push time in 2 months

startedrichgel999/miniz

started time in 3 months

more