Fiberglass flowers

Comparison of Microsoft Visual Studio unit tests (MSTest) vs NUnit, mentioning PartCover and

Till now, I did understand but didn’t remember the very situation, as I wasn’t the one creating thread pools and alike: all the core things were already there.
It’s a blessing to work for start-up.
You can think about

Monitor.Wait(toRetrieve); // will throw SynchronizationLockException

Now, after a look into docs, I see that one needs to hold the monitored object lock to avoid race conditions: a thread wakes up already holding a lock for an object it needs. The thread that did Pulse() acquired that lock and safely passed it to Wait()ing one.
Just watch out for deadlocks: it’s easy to wake up with one object lock, try to acquire another and die then…

lock(toRetrieve)
{
  Monitor.Wait(toRetrieve); // will throw SynchronizationLockException
}

As Doug Lea recommends in his excellent eternal “Concurrent Programming in Java“, just make it impossible. Lock only on a single object. If you really really need two locks, make them ordered: always acquire A then B.

If you do:

lock(a){
  // :
  lock (b)
  {
    //:
  }
  // or:
  b.SomethingThatLocks();
}

//then will you never ever do

lock(b)
{
  //:
  a.SomethingThatMightLock();
}

as calling other objects’ methods while holding a lock badly affects your karma.

For more in-detail look, read “EventWaitHandle and Monitors: how to pick one?” by Joe Duffy. He goes very deep down to system details.
He also did a nice brief overview of missed pulse problem - why do you always check wait condition in a loop:

while (toRetrieve.Count == 0)
{
  lock(toRetrieve)
  {
    Monitor.Wait(toRetrieve);
  }
}

I prefer first to identify program classes, then to think some time about its design, the longer the better.

Then, to prove my internal API idea, I make up code pieces by “wishful thinking”: how I wish the code to look, for it to be the most brief and to express core system objects and functionality, for classes to be least coupled etc etc.

I write them down to code, mock up classes, and try to make the code example work in unit test harness.

During this process I see more details: what does the API miss in order to make pieces work, especially in initialization, finalization, and whatever things were missed during initial design.

Finally I get a (huh) nearly working system core covered with readable unit tests.
I believe, not whe worst approach. Now, how can it be improved?
What did I miss?

Am I the only one who ran into .NET (or GDI?) bug with Pen (or Matrix) .ScaleTransform()?
When I scale a pen to certain width, and it has an anchor, anchor draws at inverse scale.
I might be missing something, but here’s my test. Pen scales proportionally to form width, for simplicity.

Here’s how it looks:

You see, the thinner the line, the bigger is the cap. Uh-oh.

My workaround should be here after some time.
Source code for interested ones:

Discussing Java vs C# coding conventions, I got an idea:
Geek code for a coding conventions.
Like:
-----BEGIN GEEK CODE-CODE BLOCK-----
GP:java,c,cpp,haskell
Off:2S P:N Name:Camel Flex:2
------END GEEK CODE-CODE BLOCK------

which means:

• GP:java,c,cpp,haskell - geek of programming languages (listed);
• Off:2S - prefer 2-space offsets;
• P:N - place parentheses on new line (opposed to S - same);
• Name:Camel - prefer camelCase;
• Flex(0,1,2) - I’m flexible on this and can easily accept other’s conventions.

This will help others to see what you prefer an not (?) to start stupid holy arguing.