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.

    Well, support for the GUI anyway. Command line stuff is still going to be command line stuff. For that you want it to be english. ( Have you ever tried Chinese on the command line ? )

    I am supporting French and Traditional Chinese first, because those are two of the languages that I can read/write. ( Besides English of course. )

    I originally tried using .po files for translation. That was OK, but not great. It is the supported method for wxWidgets, but that does not mean it is a great method. .po files are based on gettext, and gettext is “sub optimal”. Feel free to translate “sub optimal” as ’sucks’.

    So today, I went with a dynamic translation engine. The translations are defined at runtime using a C++ class. What is special about defining translations at runtime ?

               Plugins.

    When you define plugins, without a run time engine, you cannot add translations without editing the translation file for the entire app. So here is an example, say you write a plugin to pull the 13 week range on an equity. In chinese (HK) , that would be 13週波幅. How many people would want to edit a .po file that would get overwritten by the next update of the software? No one of course.

    By moving the plugin translations to the plugin definition file, we can get UTF8 translations that will not get overwritten by new updates. Coolness.

   So it only took….not much time to get a Raydo building under windows.

   It was very easy, much easier than I expected. Usually you expect some complication to crop up. Fresh installs are so nice, and worked perfectly this time.

    One caveat, read the instructions!! After installing VC++ 8, you have to make some configuration changes when installing the platform SDK. It boggles the mind that they (they as in M$) could not make those changes transparent when installing. That would make it much easier.

    So I checked Raydo at of the svn repository. and hit build. It compiled straight out of the box. Always nice when that happens.

    I do not know if Windows will be as supported as much as Linux or OSX. Actually I do know. It will not be supported as much. The difference is now, if there is a question or problem on windows, I can at least debug.

Blah. I still hate windows.

I have decided to add GUI support for Fedora 8 to my supported Linux distributions. Bringing the total to two, with the other as Ubuntu. The C++ & Java code still runs everywhere. I was only testing the Ubuntu version because, that is what I was using.

I started with slackware ( on floppies no less ! ) and bouncing through several distributions, I landed at Ubuntu. I was a big RedHat fan until they made the split. I just wasn’t happy with Fedora then ( And I am still not happy now ) and I started on the part to Debian systems.

So after speaking with a RedHat user, I think RedHat would be the other Linux to support. I am not supporting RedHat because of the costs ( and the Fedora thing ).

So I have downloaded Fedora 8, and I will make a new VMWare image over the weekend and start giving Fedora a try.