I am starting to use GoogleTest in development. I have not started using it YET, but I plan to roll it into my test framework. My little framework connects to a test database, and that is the thing I need to add to Google test.

I will still use my old framework. When I send work out to others , I use my framework so others do not have to worry about a xUnit framework. Not everyone uses xUnit you know.

I am a big believer in test driven development. That is just me and it has served me well.

Google’s framework for writing C++ tests on a variety of platforms (Linux, Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit architecture. Supports automatic test discovery, a rich set of assertions, user-defined assertions, death tests, fatal and non-fatal failures, type-parameterized tests, various options for running the tests, and XML test report generation.

I think it is great that Google released it.

    Well, the build process is going well. On the mac, I have made a shell script that creates the applications for you. For those of who who have not developed on a mac yet, mac applications are actually disguised folders that hold the application along with other information on running the app. Sure, it looks like just an app if you are looking at it in the finder, but it is really folder. Before, we had to build with X-Code ( the free gcc development kit from Apple Computer ) using project files and such. I really did not like going from the command line and make files to xcode JUST to make the application I could click and run. So now there is a new command in the makefile to build all the apps, or you can build the apps by doing a make in the application name and adding ‘.app.

Now onto windows … again.

    Compiling with pthreads-win32 has tons of gotcha’s. Really read the faq on the website. Some of the things I really need to stress is that if you are using an old version of MingW to develop on windows, please get the latest version. Older versions have ‘weirdness’ when it comes to pthreads. And by weirdness, I mean crashes.

    I have to hand it to the developers for putting pthreads ( POSIX 1003.1-2001 ) on Windows. They had to build it on top of the Win32 event model which is not the best. Windows NT, 2000, and XP models are different from Windows Me and the Windows 9X series. Do I think Microsoft will ever put a stake into this things and release a nice built in POSIX pthreads library that runs on all the above platforms? Not likely. Windows Me and the Windows 9X series are pretty close to dead anyway, so just do the NT kernel.

    Now Microsoft does have a pthreads implementation in Microsoft Windows Services for UNIX Version 3.5 from Interix. That runs on NT based systems, and is basically UNIX running inside of a Windows NT based box. Supposedly they have support in SUA 5.2 that I could use to build against. But I won’t. Feel free to try it yourself, but I am going to stay away from the kool-aid. If you are going to install Microsoft Windows Services for UNIX , which is basically a UNIX box, why not just install Fedora or Ubuntu and call it a day?

    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.

   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.