Stars
525
Forks
41
Watchers
525
Open Issues
3
Overall repository health assessment
No package.json found
This might not be a Node.js project
46
commits
Added programming test of timers and cleaned up the "basic" programming test
7d9cb19View on GitHubWoho. Epic commit with hierarchical tasks, function calls, SPAWN instruction, task message passing, etc etc. Still WIP, but tests pass and main.c runs
74e10cfView on GitHub[breaking wip] Added preliminary Task Identifier map together with a new task structure.
6b3b323View on GitHubAdded Multiple Producer, Single Consumer lock-free FIFO message queue. This little guy only cost a single XCHG (for the producer, best-case scenario) and worst-case additionally one XCHG for the consumer. Benchmarks show very good numbers. When there are 2-7 producers (each running on a separate OS thread) and one active consumer (which is running on yet another separate OS thread, sitting in a loop just trying to dequeue), the average time taken for one transaction (malloc message, enqueue, dequeue, verify, free) is 120 nanoseconds on a 2.3 GHz Intel Core i7, 1600 MHz DDR3 memory (MacBook Pro late 2012). Graph: http://farm9.staticflickr.com/8192/8099092455_ec05f646df_b.jpg
c95e8b8View on GitHubAn early implementation of hierarchical tasks. When a task A spawns a new task B, B retains a reference to A. If B dies before A, A is dereferenced (B releases its reference). If the supertask A dies before B, a specialized garbage collector (called CheckZombie) is executed which will clean up (kill off) any subtasks. Each level of subtasks will be kileld in cycles, so to avoid resource usage spikes when collecting large number of subtasks. However, this implementation and design is restricted to a single OS thread as we rely on control flow and memory state. It is possible to use locking and counting to allow multiple OS threads, but that would make this design inefficient. A networked model is impossible due to the heavy use of shared memory.
7380103View on GitHub