| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
and it runs faster as well, about 2/3 of the performance we have when being in serial mode
|
| |
|
|
|
|
| |
Condition implementation, related to the notify method not being treadsafe. Although I was aware of it, I missed the first check which tests for the size - the result could be incorrect if the whole method wasn't locked.
Testing runs stable now, allowing to move on \!
|
| |
|
|
|
| |
queue: Queue now derives from deque directly, which safes one dict lookup as the queue does not need to be accessed through self anymore
pool test improved to better verify threads are started correctly
|
| |
|
|
|
|
| |
thread-safe, causing locks to be released multiple times. Now it runs very fast, and very stable apparently.
Now its about putting previous features back in, and studying their results, before more complex task graphs can be examined
|
| |
|
|
| |
events only with its queue, with boosts performance into brigt green levels
|
| |
|
|
| |
the time instead of reusing its own one, it was somewhat hard to manage its state over time and could cause bugs. It works okay, but it occasionally hangs, it appears to be an empty queue, have to gradually put certain things back in, although in the current mode of operation, it should never have empty queues from the pool to the user
|
| |
|
|
| |
thing as the task deletes itself too late - its time for a paradigm change, the task should be deleted with its RPoolChannel or explicitly by the user. The test needs to adapt, and shouldn't assume anything unless the RPoolChannel is gone
|
| |
|
|
| |
task class
|
| |
|
|
| |
the wrong spot. The channel is nothing more than an adapter allowing to read multiple items from a thread-safe queue, the queue itself though must be 'closable' for writing, or needs something like a writable flag.
|
| |
|
|
| |
unnecessary tasks to be scheduled as we keep track of how many items will be produced for the task at hand. This introduces additional locking, but performns well in multithreaded mode. Performance of the master queue is still a huge issue, its currently the limiting factor, as bypassing the master queue in serial moode gives 15x performance, wich is what I would need
|
| |
|
|
| |
still inconsistencies that need to be fixed, but it already improved, especially the 4-thread performance which now is as fast as the dual-threaded performance
|
| |
|
|
| |
for up to 2 threads, but 4 are killing the queue
|
| |
|
|
| |
havok - lets call this a safe-state
|
| |
|
|
| |
single task for now, but next up are dependent tasks
|
| |
|
|
| |
chunking test. Next up, actual async processing
|
|
|
including own tests, their design improved to prepare them for some specifics that would be needed for multiprocessing support
|
