So I was dorking around this weekend with the threading model on Raydo. Mainly benchmarking the granularity of the threads. For what I normally do , everything seems fine, equities, futures, blah, blah,blah. Until I started simulating a market maker carrying tons of options quotes on his/her book. The old model started to have a ‘lag’ that I was not happy about. So I started benchmarking a finer/coarser grained threading models.

    I am using pthreads which run on real ( POSIX ) systems, and Pthreads-win32 for that other operating system. So I am looking through the pthreads documentation for pthreads read / write locks , in the Linux/Mac/rest of the world documentation, I see this.

To prevent writer starvation, writers are favored over readers.

Which is nice, and IMHO, the way reader/writer locks should be. However for Windows, I see this lovely pearl of wisdom,

Pthreads-win32 does not prefer either writers or readers in acquiring the lock – all threads enter a single prioritised FIFO queue. While this may not be optimally efficient for some applications, it does ensure that one type does not starve the other.

    Argh ! “optimally efficient”? How about sucks? I do not want a fresh tick quote to come in, and have 20 readers in the queue before the writer reading a stale tick quote. I want the writer bumped to the front of the queue, dump the new tick in, and have the readers read the new data. Another reason I don’t like windows.

    Pthreads is just a wrapper around Win32 threads, and from what I am reading, Win32 does not really support multi-read, single-write (MRSW) lock that does not have problems with writer starvation. ( In NT they have an undocumented lock, which I guess is only for some nefarious MS usage.) So don’t quote me on the Win32 API. I am not a Win32 API guy, but it seems the Win32 API has a problem with writer starvation in reader/writer locks. Please correct me if I am wrong.

    Whatever model I use, when running a lot of reader / writer threads, I think I will have not have the warm fuzzies using Pthreads.

[Update] Just changed the object model a little bit, and everything is back to goodness. I did learn something about the Win32 API along the way that I did not want to know.