Posts

Showing posts from July, 2008

Learning LINQ to SQL (Part 2)

In my last post, I had worked through a few section of the white paper "LINQ to SQL: .NET Language-Integrated Query for Relational Data" and had gotten a working LINQ program going.

Everything was going just fine... until now. At the end of the Defining Relationships section, the article leaves me kind'a hanging. It says "there is a tool (described later) that can be used to generate all the necessary definitions..." So, I've got to go back to the TOC to see what this "special tool" is for generating the Entities.

I jump to "The Entity Class Generator Tool" section and start reading. My first order of business is to find the program called SqlMetal. I launch a COMMAND window and type "sqlmetal" and receive the expected "'sqlmetal' is not recognized as an internal or external command." error. Hey, it was worth a try! So, I next use the old stand-by "cd \" then "dir /s sqlmetal.*". Yup,…

Learning LINQ to SQL

I've decided to spend a little time these next few evenings coming up to speed on LINQ (Language-Integrated Query) and writing about my experience with it. Let's see what sorts of problems I run into. I'm using as reference the 119 page LINQ to SQL: .NET Language-Integrated Query for Relational Data in order to jump start my learning. I hope that my SQL and C# experience will give me a head start and keep me moving. But, I have done nothing yet with the Northwind sample database (the database used in the white paper) in any of my projects or tests. I am not even sure where to get it yet. Ha, ha, Noobie on the loose, let me at it...

Let's Create some Entity Classes. The white paper starts out with creating entity classes. Granted, I'm starting in the "Quick Tour" section of the white paper, so I expect to find some detail ommisions. I'll take my chances. So, I jump right into the declaration of the Customer class.

[Table(Name="Customer…

Timers are a Changin' (Part 3)

In my last couple of articles, we saw the System.Windows.Forms.Timer and the System.Timers.Timer. Today, I shall look at the 3rd form of Timer in the .NET library, the System.Threading.Timer. I refer you again to the that very good article I mentioned a while back, Comparing the Timer Classes in the .NET Framework Class Library by Alex Calvo. Take a moment to read his section on System.Threading.Timer then come back and we will jump right into some code...


using System.Threading;
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
timer1 = new System.Threading.Timer(new TimerCallback(timer_elapsed), null, 2000, 1000);
}

System.Threading.Timer timer1;
private void timer_elapsed(object sender)
{
Console.WriteLine(DateTime.Now.ToString());
TimerEvent(DateTime.Now.ToString(), Thread.CurrentThread.GetHashCode().ToString());
}

private delegate void TimerEve…

Timers are a Changin' (Part 2)

Today, I take a look at System.Timers.Timer. I suggested an article in my last discussion of timers. The article was written back in 2004, and it says that both the System.Windows.Forms.Timer and the System.Timers.Timer are found in the IDE Toolbox, one on the Windows Forms tab and the other on the Components tab. Well in my stock installation of Visual Studio 2008, both of those timers are System.Windows.Forms.Timer components. This may be due to some install problem I didn't know I had, or it may be the article is correct for Visual Studio .Net 2003 but not 2008.

That's okay because you can just add System.Timers.Timer to your project the old fashioned way. I simply start a new Windows Forms project and name it TimerExample2. After dropping a label on my form, I add the following code to my class file (I include a full listing at the end).


System.Timers.Timer timer1; //added
public Form1()
{
InitializeComponent();
// added the …

Timers are a Changin' (Part 1)

Sometimes mundane things turn out to be really nice after all. No, I'm not talking about one of your last dates. I'm talking about timers, yes, the Timer classes in C#. These little tools are found everywhere in programming, and it seemed for the longest time, there was only one stock timer to choose from. Well, now there are three.

Before I go any further, let me recommend to you Alex Calvo's MSDN magazine article Timers: Comparing the Timer Classes in the .NET Framework Class Library. Here, you will find some good background for applying timers to your application.

But, in this little series, I want to look at how the timers interact with the event loop. This first article in the series will look at the System.Windows.Form.Timer.

The System.Windows.Form.Timer is supposed to be synchronous with respect to the rest of your Windows Forms app. That means, if you "sleep" or block in some other way, the timer will stop working (while sleeping). However, programm…

Why Try? Finally!

Today we talk about the "try/finally" construct. This article should be very simple for most of you with any C# or C++ experience to understand. I've written a sample that you will find at the end of this article to let you see the various affects of the "finally" statement under different scenarios.

But why use "finally" at all? I like to think of "finally" as being to the flow of logic what the "destructor" or "dispose" is to the life of an object. It is a common place to put all the necessary logic for shutting down the logic context. With the ubiquitous "execption" lurking behind every corner, you never know when you will be forced to leave the context, and it's nice to have a place for common cleanup code. You say you could just write the cleanup in the common exception handler. But then you have to repeat the code, line for line, in every other named exception handler as well as the error free …

Thread Synchronized Queing

Today's topic gets back to some multi-threading. I find it very useful to have threads pull work from a queue and have one master assignment manager feed the queue. However the standard System.Collections.Generic.Queue is a little inadequate for me because it is not fully thread-safe. I found it a little disheartening that the Queue class members are not overridable either. So we write our own, here are my requirements...


The queue must synchronize multiple writer threads writing elements to the queue.
The queue must synchronize multiple reader threads reading from the queue.
If there is nothing in the queue, a reader thread must wait for something or timeout.
Those waiting on the queue can be “interrupted”.
Of course, no two readers will ever get the same element off the queue.


So let's start coding...

I start with a new class called SyncQueue in my own name space and I will make it generic.


namespace QueueExample
{
public class SyncQueue
{
public void Enqueue(T element)
{
// we&…

Locking Guidelines

In my last post (Lock Up Unlocked), I gave you some basic guidelines for locking resources in multi-threaded programs.

Basic guidelines for locking.

Avoid simultaneously locking multiple shared resources in a single thread.
If multiple shared resources must be locked simultaneously, endeavor that all threads lock the resources in the same order and unlock them in reverse order.
If they can't be unlocked in reverse order, then endeavor to unlock in the same order and do not lock an earlier resource till all later locks are released.
If you can't follow these guidelines, then timeout.


In today's post, I am going to elaborate a little on each principle. But first, let's discuss "resources". Many of you can quickly name the commonly understood resources. Things like memory, cpu, network jump right out, but that's because we are so used to looking at Task Manager and Resource Monitor. Besides, they are a little esoteric, programmers are concerned about specific…

Lock Up Unlocked

In my last post (Locked Up!), I gave an example of a simple deadlocking application. If you run it and click the button a few times rapidly, the application stops responding. Then, if you pause the program and examine the stack trace of each thread, you find the GUI thread waiting for the lock, and the child thread waiting for Invoke() to return. The child thread is holding the lock, so the application is deadlocked. This is also known as a "deadly embrace".

So, I affectionately referred to the two resources as Resource RA and Resource RB and asked you to identify them in the program. One of the resources is pretty obvious. That would be the lblResult.Text. It doesn't matter whether you call this RA or RB, so I'll call it Resource RA. Regardless, for some odd reason, the programmer has decided that the lblResult.Text property needs to be protected from simultaneous read and write. This protection is not really necessary, but pretend for a moment a valid sort …

Locked Up!

Today's example is NOT useful code. Instead, it's a simple example of a bad practice in multi-threaded code floating around out there in programming land. This example is C# specific, but the concepts apply to other languages as well.

Since this is a bad example, I'll start off by telling you why its bad. The application locks then blocks on another resource. It's as simple as that. Many of you understand that if Thread A locks Resource RA and tries to lock Resource RB, while Thread B locks Resource RB and then tries to lock Resource RA, you have a classic "deadlock".

The following code "deadlocks". Run it and click the button a few times and it will deadlock. So, the real question is not "why is it deadlocking?" I just told you up front, it's a classic deadlock. The real question is "what are the equivalents in this program of Resources RA and RB?"

To answer this question, you can run the program in your favorite debu…