ATL UG, Paul Wilson, and a shiney new book!

<< IE 7 beta 2 publicly available | Home | Tools post a while ago >>

ATL UG, Paul Wilson, and a shiney new book!

I gave a presentation on monday about creational patterns at the ATL C# users group. I gave a presentation last month on AOP in .NET, there were actually alot of people at this one; I forgot how much I hate public speaking of course patterns are something I am passionate about so the nervousness went away rather quickly. Last night I was (re) reading Joel's interviewing advice and he discusses people being passionate and forgetting nervousness; let me say it is true.

I won a book at the UG as well ! seems to be a good one so far real “light“ reading http://www.amazon.com/exec/obidos/tg/detail/-/0321154932?v=glance although I have been needing a copy of this with all the IL work I have been doing.

One of the members Ken http://www.dotnetjunkies.com/WebLog/kenbrubaker/archive/2006/02/07/atlcshartugfeb2006.aspx brought up the importance of dependency injection in talking about factories.

I love all of the fancy names for basic concepts I never learned it as dependency injection, I just learned it as using a registerrable factory so a client of the library could register their own classes for use with the factory. I guess there is someone in acadamia making up cool names for everything.

Also got to finally meet Paul Wilson http://weblogs.asp.net/pwilson after numerous discussions with him online. If you havn't checked out his OR mapper I would definately recommend taking a quick look. I won't say that it has all of the neat features of some of the other OR mappers; it is relatively simple and due to this offers a much smaller learning curve than many other OR mappers, that and it works like a charm. There are numerous production systems running off the code base and it is fairly stable at this point unlike some other OR mappers I know of.

If you read the above paragraph and have NO idea about what I am talking about. Jimmy Nilsson has a great book http://www.amazon.com/exec/obidos/tg/detail/-/0321268202/qid=1139455312/sr=1-2/ref=sr_1_2/103-6679997-8727033?v=glance&s=books coming out this spring that ties together the concepts presented in P of EAA by Fowler and DDD by Eric Evans and goes through implementations in C#. If you are not familiar with DD, I invite you to get a copy and have a very one sided discussion with Jimmy about why its a better way of doing things. I would also highly recommend reading the two books mentioned (they should both be on every OO developer's shelf).

Another item that was discussed after my presentation is the concept of trying to make all objects have a new when dealign with your class library so some less sophisticated developers have an easier time understanding the libray. After thinking about this for a few moments I have slightly changed my style to include this, I have been putting wrapper classes for factoried objects so that users can directly construct a wrapper which talks directly to the factory (hiding the concept of a factory from them). I think it in general provides a better interface and in some cases I can completely hide the factory which is nice, it makes the system seem alot less complex.

Yet another point that just came out of the abyss of my mind when discussing thread safety on the singleton is a common mistake I see people making.

public class Foo {
   private string m_Bar;
   public string Bar {
        get { lock(this) { return m_Bar; } }
        set { lock(this) { m_Bar = value; }}
}

The locks are completely not necesary here and will slow your code to a crawl the return and the assignment operations here are guarenteed to be atomic, it is therefore wasteful to put additional locking around them.

I believe the general rule is ...

Any item which is a reference or a value type which is of the same size or smaller than the reference size is guarenteed to be atomic.

I may be wrong but I know I am atleast close so feel free to correct me :)

Print posted @ Wednesday, February 08, 2006 7:09 PM

Feedback

# re: ATL UG, Paul Wilson, and a shiney new book!

Hi Greg,
I think your example of Foo is a bit synthetic. If you need locking or not depends on your requriements. If you can live with it to get old data then the above sample is ok for string types but certainly not for all reference and value types. If your object is not a singleton your lock(this) is wrong since you are locking on the type which is the same for all instances. A more realistic sample needs locking after all
public static class Log
{
private object sync = new object();
private LogWriter writer;

public LogWriter Logger
{
get
{
if (writer == null)
{
lock (sync)
{
if (writer == null)
{
writer = factory.Create();
}

}
}
return writer;
}
}
Even with no setter we need locking to initialize our variable. Concurrent access to the getter from different threads would lead to double initialization and a waste of resources. When you introduce a setter things will become even more complicated. You did assume that the assignment operation is atomic. It is not! You should be aware that during the assigment operation many instructions happen (memberwise copy of values types) which can be interrupted and let another reader retrieve a half overwritten object.

Yours,
Alois Kraus
2/12/2006 2:40 AM | Alois Kraus

# re: ATL UG, Paul Wilson, and a shiney new book!

I think you completely missed the point of my post.

What I am saying is that with variable assignments the operations are atomic and therefore one does not need to lock.

In your example the operation is far from atomic and would require locking.

What I am talking about is the exact simplified example where say a string is being set, there is no need to lock. The assignment of the string to the internal member is assured to be atomic.

"You should be aware that during the assigment operation many instructions happen (memberwise copy of values types) which can be interrupted and let another reader retrieve a half overwritten object. "

hence why I put the size rule on.
2/12/2006 3:01 AM | Greg Young

# re: ATL UG, Paul Wilson, and a shiney new book!

oh .. could you explain this a bit further?

"If your object is not a singleton your lock(this) is wrong since you are locking on the type which is the same for all instances. A more realistic sample needs locking after all "

lock(this) locks on the instance not on the type. in fact in order to lock on the type (a global lock you use lock(typeof(foo)))
2/12/2006 3:37 AM | Greg Young

# re: ATL UG, Paul Wilson, and a shiney new book!

.§$%§$% my first answer got lost. I was wrong on the "is the same for all instances". It is correct but bad practice this it was I should have remembered: http://blogs.msdn.com/ericgu/archive/2005/04/22/410809.aspx#410814

I find the rule difficult to understand (what is Item?) and what the area of applicibality exactly is. This can lead some readers (me) to get the intention of the rule wrong.

Yours,

Alois Kraus
2/12/2006 4:02 AM | Alois Kraus

# re: ATL UG, Paul Wilson, and a shiney new book!

lock(this) is bad anyways. Since "this" is an instance of public class Foo, pretty much anything in the current appdomain could have a reference to it... and could open a lock on it, just for the hell of it (or by mistake). Same reason it is bad to lock on any Type or literal string or any other publicly visible object. 2/22/2006 10:22 PM | Keith Rome

# re: ATL UG, Paul Wilson, and a shiney new book!

keith see the follow up post ... I used "this" as a quick piece of code cause I am lazy. 2/22/2006 10:48 PM | Greg Young

Greg Young