emper merge requestshttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests2022-05-14T15:34:45Zhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/384pulse: busy loop when evenly introducing work2022-05-14T15:34:45ZFlorian Fischerpulse: busy loop when evenly introducing workWhen evenly introducing work the sleep continuation of the pulser fiber
is possibly delayed due to the worker executing an introduced work items
distorting the pulse.
This distortion does not occure when the pulser busy loops between
in...When evenly introducing work the sleep continuation of the pulser fiber
is possibly delayed due to the worker executing an introduced work items
distorting the pulse.
This distortion does not occure when the pulser busy loops between
introducing work items. We do not count the busy looping worker running
the pulser when calculating the work items to reach the target utilization.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/362introduce simple CallbackHandle2022-03-15T14:20:40ZFlorian Fischerintroduce simple CallbackHandleA CallbackHandle is used to cancel a previosuly submitted future with
set callback without keeping the future object around.
A CallbackHandle remembers the callback pointer and the IoContext
where the callback was submitted to submit a ...A CallbackHandle is used to cancel a previosuly submitted future with
set callback without keeping the future object around.
A CallbackHandle remembers the callback pointer and the IoContext
where the callback was submitted to submit a cancel operation for the
pointer on the same IoContext.
A CallbackHandle can be obtained by calling
Future::submitAndGetCallbackHandle().https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/227[IO] add FutureSelector to multiplex waiting on multiple Futures2021-09-13T13:48:39ZFlorian Fischer[IO] add FutureSelector to multiplex waiting on multiple FuturesA FutureSelector is internally implemented as a Sempahore and a
vector of monitored Futures.
All Futures monitored by the selector know the selector
and signal its semaphore on completion.
When the FutureSelector's Semaphore is released ...A FutureSelector is internally implemented as a Sempahore and a
vector of monitored Futures.
All Futures monitored by the selector know the selector
and signal its semaphore on completion.
When the FutureSelector's Semaphore is released the select
unblocks and searches for the first ready Future in its list.
NOTE: The FutureSelector is except its Semaphore not thread-safe
and must not be used in parallel.
This means no Futures can be retrieved from or passed to other Fibers
which would possibly result in parallel modification of the selector
during Future destruction.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/201add io_uring buffer support2021-08-19T12:34:43ZFlorian Fischeradd io_uring buffer support1. Add generic WaitQueue to model a BufferGroup
2. Introduce RutimeBuilder to build a Runtime object with initial worker hooks.
This is needed to register a BufferGroup on each worker's IoContext
4. Misc changes to Fiber and PrivateSe...1. Add generic WaitQueue to model a BufferGroup
2. Introduce RutimeBuilder to build a Runtime object with initial worker hooks.
This is needed to register a BufferGroup on each worker's IoContext
4. Misc changes to Fiber and PrivateSemaphore to allow PrepareBuffersFutures to be used in new worker hooks
3. Extend the Future API and add the actual buffer code
~~**TODO**:
Fix the BufferGroup wait problem.~~
The problem can be observed with the ConcurrentRegisteredBufferTest. Buffer notifications are not global and a notified Fiber may not wakeup on the worker where the notification happend.
**Possible solutions**:
* Allocating new buffers if the group is empty and register them costing a syscall (**not possible. because updating the registered buffers needs the ring to idle**)
* Dispatch the notified Fiber on notification so it will always wake up on the worker where the buffer is available and
schedule the continuation of the notifying Fiber (**not possible. It can not be controlled where a Fiber wakes up even using a direct dispatch because the notifying Fiber may not currently run on the Worker where the waiting Fiber was suspended**)
Waiting for a RegisteredBuffer is not supported anymore. The user can try to get one of the current worker or call
`RegisteredBuffer::getOrAlloc()` which will use a free registered one or tranparently allocate a new buffer.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/140Draft: Introduce and use emper::exit2021-04-12T09:38:10ZFlorian FischerDraft: Introduce and use emper::exitCalling `exit(3)` from within the runtime is racy because some worker
threads could hold references to resources which are freed by the thread
calling `exit(3)`.
To solve this problem the new functions `emper::exit(int)` and `empe...Calling `exit(3)` from within the runtime is racy because some worker
threads could hold references to resources which are freed by the thread
calling `exit(3)`.
To solve this problem the new functions `emper::exit(int)` and `emper_exit(int)`
are introduced which initiate the termination of the runtime and exit
the current worker thread.
We have to ensure that no worker thread is using resources that are owned and
freed by other threads. This is done with a Latch that the workers use to synchronize
before actually terminating.
The exit status specified by the worker thread is propagated to the
thread calling `Runtime::waitUntilFinished` which will call `exit(3)` with
the worker provided status.
Fixes #14.