eris Wrote: > My library uses a straight-forward reactor approach to handle incoming events > (IO, > timer etc). The library is structured as one-thread-per-core and as many > co-routines (fibers) per thread as memory will allow. The threads communicate > with each other via lock-free single-writer, single-reader FIFOs. > > Each threadCore has it's own reactor with the only limitation that only the > threadCore0 reactor (the default thread) can wait for signals / child > processes. > > Windows uses a "proactor" model instead of reactor, so it schedules I/O first > and > then waits for an IO completion flag. I've modified my reactor so that it > presents > a reactor facade even on Windows systems. Performance suffers a bit, but you > pick > your platform and you takes your chances. >
I will admit that I don't understand lock-free that well, but I have implemented thread safe lists before. In my case, it allowed multiple readers (they just increased one locked variable that held the count of how many readers, and decreased on finish reading). This allowed multiple readers to read from it. Whenever a writer decided it needed access, it would hit write, and wait for all the current readers to free themselves from the list. Then it would have exclusive access and write. The reason I mention this is the multiple readers. Allowing multiple reads would increase performance imo. Why is it that you don't do this? The other thing is, what if one core becomes completely free, are you waiting for an event to be mapped to a core? why not have each core steal events as needed. This would allow that no core becomes overloaded with long tasks and that all cores get to work even when new events aren't being mapped but long running events are currently mapped.
