Thread contention and static methods

[C.]

Hello,

I have always made CRUD methods on my Business Objects static.
However, after going through the MS cert training kit 70-515, I came
across this:

"if the business layer uses static methods (or shared methods, in
Visual Basic), the ObjectDataSource can use these
methods without creating an instance of the actual business object. In
this case, however, keep
in mind that you could end up with performance issues related to
thread contention as multiple
requests try to access the same static method."

This passage would seem to suggest that each thread can only enter a
static method one at a time. If so, wouldn't this cause scalability
issues if a static method is used frequently in an application?

I had never heard this, any explanation would be appeciated!

Chris

 

[Registered User]

Hello,

I have always made CRUD methods on my Business Objects static.
However, after going through the MS cert training kit 70-515, I came
across this:

"if the business layer uses static methods (or shared methods, in
Visual Basic), the ObjectDataSource can use these
methods without creating an instance of the actual business object. In
this case, however, keep
in mind that you could end up with performance issues related to
thread contention as multiple
requests try to access the same static method."

This passage would seem to suggest that each thread can only enter a
static method one at a time. If so, wouldn't this cause scalability
issues if a static method is used frequently in an application?

Multiple threads can operate within a static method at the
simultaneously. There is no thread safety; changes to static members
by one thread are visible to other threads.

Copy the example below into a console app and play with the value of
sleepFor. The value of name and Thread.CurrentThread.Name may or may
not be the same inside the if statement. There is also a possibility
both threads will enter the if statement; the second thread might use
the original value of done before the first thread changes that value
to true.

static void Main(string[] args)
{
Thread.CurrentThread.Name = "main";
Thread worker = new Thread(Go);
worker.Name = "worker";
worker.Start();
Go();

Console.ReadKey();
}

static bool done;
static string name;
static int sleepFor = 10000;
static void Go()
{
name = Thread.CurrentThread.Name;
Console.WriteLine("Sleep : {0} : {1}", name,
Thread.CurrentThread.Name);
Thread.Sleep(sleepFor);
if (!done)
{
done = true;
Console.WriteLine("Done : {0} : {1}", name,
Thread.CurrentThread.Name);
}
}

To make the method thread-safe a lock can be used. The results are
more predictable because only one thread at a time is in the body of
the static method.

static readonly object obj = new object();
static void Go()
{
lock (obj)
{
name = Thread.CurrentThread.Name;
Console.WriteLine("Sleep : {0} : {1}", name,
Thread.CurrentThread.Name);
Thread.Sleep(10000);
if (!done)
{
Console.WriteLine("Done : {0} : {1}", name,
Thread.CurrentThread.Name);
done = true;
}
}
}

I had never heard this, any explanation would be appeciated!

Probably not the best explanation but it does fall under the 'any'
flag...

regards
A.G.

 

[Arne Vajhøj]

I have always made CRUD methods on my Business Objects static.

Not good.

Too tightly coupled. An interface is good - a class with virtual methods
that can be overriden can do.

However, after going through the MS cert training kit 70-515, I came
across this:

"if the business layer uses static methods (or shared methods, in
Visual Basic), the ObjectDataSource can use these
methods without creating an instance of the actual business object. In
this case, however, keep
in mind that you could end up with performance issues related to
thread contention as multiple
requests try to access the same static method."

This passage would seem to suggest that each thread can only enter a
static method one at a time. If so, wouldn't this cause scalability
issues if a static method is used frequently in an application?

Multiple threads can certainly call the same static methods at
the same time.

I will guess that the real story is:
- multiple threads calling the same static methods works perfect
if the method only uses local variable
- if it uses static fields and it does not synchronize then it is
not thread safe
- if it uses static fields and it does synchronize then it is
performance can suffer
- by using non static fields and methods each thread can get its
own instance to use which will be both thread safe and perform

Arne

 

[Registered User]

Correction: "changes to static members by one thread _might_ be visible
to other threads".

In this context the words 'can' and 'might' carry equivalent meanings.
Neither one bears the explicit promise of 'will'.

- good stuff snipped -

All that said, the bottom line here is the same what you essentially
describe and as I wrote before: for a _plain_ C# program, without any
explicit synchronization, static methods are not synchronized. In other
contexts, this may or may not continue to hold to be true.

The sample demonstrates the OP's inference is incorrect.

- quote -

This passage would seem to suggest that each thread can only enter a
static method one at a time.

- end quote -

I didn't see a reason for further detail. Besides if further detail is
necessary, there are people like you who can explain things much
better than I.

regards
A.G.

 

[Arne Vajhøj]

I have always made CRUD methods on my Business Objects static.
However, after going through the MS cert training kit 70-515, I came
across this:

"if the business layer uses static methods (or shared methods, in
Visual Basic), the ObjectDataSource can use these
methods without creating an instance of the actual business object. In
this case, however, keep
in mind that you could end up with performance issues related to
thread contention as multiple
requests try to access the same static method."

This passage would seem to suggest that each thread can only enter a
static method one at a time. If so, wouldn't this cause scalability
issues if a static method is used frequently in an application?

Multiple threads can operate within a static method at the
simultaneously. There is no thread safety; changes to static members
by one thread are visible to other threads.

Copy the example below into a console app and play with the value of
sleepFor. The value of name and Thread.CurrentThread.Name may or may
not be the same inside the if statement. There is also a possibility
both threads will enter the if statement; the second thread might use
the original value of done before the first thread changes that value
to true.

static void Main(string[] args)
{
Thread.CurrentThread.Name = "main";
Thread worker = new Thread(Go);
worker.Name = "worker";
worker.Start();
Go();

Console.ReadKey();
}

static bool done;
static string name;
static int sleepFor = 10000;
static void Go()
{
name = Thread.CurrentThread.Name;
Console.WriteLine("Sleep : {0} : {1}", name,
Thread.CurrentThread.Name);
Thread.Sleep(sleepFor);
if (!done)
{
done = true;
Console.WriteLine("Done : {0} : {1}", name,
Thread.CurrentThread.Name);
}
}

To make the method thread-safe a lock can be used. The results are
more predictable because only one thread at a time is in the body of
the static method.

static readonly object obj = new object();
static void Go()
{
lock (obj)
{
name = Thread.CurrentThread.Name;
Console.WriteLine("Sleep : {0} : {1}", name,
Thread.CurrentThread.Name);
Thread.Sleep(10000);
if (!done)
{
Console.WriteLine("Done : {0} : {1}", name,
Thread.CurrentThread.Name);
done = true;
}
}
}

I had never heard this, any explanation would be appeciated!

Probably not the best explanation but it does fall under the 'any'
flag...

I think the point of two threads running in the same static
method can be illustrated simpler:

using System;
using System.Threading;

namespace E
{
public class Program
{
public static void Main(string[] args)
{
(new Thread(Go)).Start();
(new Thread(Go)).Start();
Console.ReadKey();
}
public static void Go()
{
Console.WriteLine("Thread " + Thread.CurrentThread.ManagedThreadId +
" starting at " + DateTime.Now.ToString("HH:mm:ss.fff"));
Thread.Sleep(1000);
Console.WriteLine("Thread " + Thread.CurrentThread.ManagedThreadId +
" ending at " + DateTime.Now.ToString("HH:mm:ss.fff"));
}
}
}

Arne

 

[Arne Vajhøj]

In this context the words 'can' and 'might' carry equivalent meanings.
Neither one bears the explicit promise of 'will'.

True.

But the word "are" carry a meaning that is equivalent of "will".

Arne