Thread contention and static methods

  • Thread starter Thread starter C.
  • Start date Start date
C

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
 
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?
Click to expand...
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!
Click to expand...

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

regards
A.G.
 
I have always made CRUD methods on my Business Objects static.
Click to expand...

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?
Click to expand...

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
 
Correction: "changes to static members by one thread _might_ be visible
to other threads".
Click to expand...

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.
Click to expand...

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.
 
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?
Click to expand...
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!
Click to expand...

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

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
 
In this context the words 'can' and 'might' carry equivalent meanings.
Neither one bears the explicit promise of 'will'.
Click to expand...

True.

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

Arne
 
Back
Top