I have set up a mailing list for announcements. A low volume list, so it won’t clog you mailbox. I think MAYBE once a month. Drop me an email and I will put you on the list. info @ raydo.com

I am testing out changing the build system to CMake. I want to make building Raydo as simple as possible. Right now I use make, which is not the friendliest way to build things. By using CMake, I can supply , for example, Visual C project file.

So to summarize:
Open Source
  Supports basically every UNIX, MS Windows (MSVC, Borland, cygwin, mingw) and Mac OS X
  Can generate Makefiles and *projects* for KDevelop3, MSVC 6,7, XCode
  Has no other dependencies except for a C++ compiler

So I will be able to supply Windows guys with project files.

Ok, so I have Raydo.org now. This will be the mailing list site eventully. I don’t know when I will get it up and running , so for now, keep sending emails directly to my email account.

    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 on to plugin’s in Raydo. The computation functions I am trying to make it easier to add computation, almost like ‘plugin’s. I say ‘plugin’, and when I say plugin, I mean compiled into the code. Doing binary ‘plugins’ is just crazy. The only reason to do that is closed source code. If you have the source like Raydo, it makes much more sense to compile it in.

    So when you write a plugin, you have to worry about threads. The computations are done out in the threads, so you have to be careful to use thread safe functions.

    Certain C++ Standard Library functions from C are particular problems because they hold internal state between calls.

rand & strtok will probably not be a problem. The time functions (asctime, ctime, gmtime, localtime) you may end up trying to use but you shouldn’t.

    Some vendors ( like HP ) have thread-safe replacements for these functions, with different names and arguments, but you should realize that these are not portable. You can write thread-safe implementations using thread-specific storage, if you want to.

    If you really want something portable & thread safe, I suggest you use the Boost replacements for the problem functions. I will go into why I am not including Boost in the build at a later time.

Well, I just spoke to someone ( who shall remain nameless ) at OptionsHouse, and they are not going to have an API for a while. They have lot of requests for an API, but I think they are a little too busy to push it out for traders. They do not have an estimate, but you know how estimates are anyway.

They are good guys over at OptionsHouse, and I am sure they will get the API out sooner rather than later.

The Problem with Threads is a paper written by the Edward A. Lee, the Chair of EE @ University of California at Berkeley

I especially liked one line from his conclusion,

Concurrent programming models can be constructed that are much more predictable and understandable than threads. They are based on a very simple principle: deterministic ends should be accomplished with deterministic means.

Until that day comes, we will still muddle along with pthreads. Once again, threads in Windows is a pain!

( Well not really a pain, just why do they have to be different ? )

Over there, on the right hand side of the page.