if threads don't Sleep, synchronization will fail to occur ?!

  • Thread starter Thread starter pokémon
  • Start date Start date
P

pokémon

OK, if you run this code below (Console app) you will find that threads will
not always behave in a synchronized fashion, even with a lock
statement, --unless you put a Sleep somewhere in the method passed to
ThreadStart.

Try it, and please prove me wrong.

********
using System;
using System.Threading;
namespace TestLockPrivate
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
innerClass2 a = new innerClass2();
a.startme();
innerClass2 b = new innerClass2();
b.startme();
innerClass2 c = new innerClass2();
c.startme();
}

public class innerClass1 {
private object alock = new object();
private static string str = "";
public void foo() {
lock(alock) {
str = Thread.CurrentThread.GetHashCode().ToString();
if (str !=
Thread.CurrentThread.GetHashCode().ToString()) {
Console.WriteLine("str = " + str + "
Thread.CurrentThread.GetHashCode().ToString() = " +
Thread.CurrentThread.GetHashCode().ToString());
}
}
}
}

public class innerClass2 {
public Thread t = null;
public void startme() {
t = new Thread(new ThreadStart(threadMain));
t.Start();
}
public void threadMain() {
while (true) {
innerClass1 l = new innerClass1();
l.foo();
}
}
}
}
}
 
You are right! I added the static modifier to alock and now it is
synchronized.

But, can you please explain 3) below. I don't understand.


Willy Denoyette said:
pokémon wrote:
|| OK, if you run this code below (Console app) you will find that
|| threads will not always behave in a synchronized fashion, even with
|| a lock
|| statement, --unless you put a Sleep somewhere in the method passed to
|| ThreadStart.
||
|| Try it, and please prove me wrong.
||
|| ********
|| using System;
|| using System.Threading;
|| namespace TestLockPrivate
|| {
|| class Class1
|| {
|| [STAThread]
|| static void Main(string[] args)
|| {
|| innerClass2 a = new innerClass2();
|| a.startme();
|| innerClass2 b = new innerClass2();
|| b.startme();
|| innerClass2 c = new innerClass2();
|| c.startme();
|| }
||
|| public class innerClass1 {
|| private object alock = new object();
|| private static string str = "";
|| public void foo() {
|| lock(alock) {
|| str =
|| Thread.CurrentThread.GetHashCode().ToString();
|| if (str !=
|| Thread.CurrentThread.GetHashCode().ToString()) {
|| Console.WriteLine("str = " + str + "
|| Thread.CurrentThread.GetHashCode().ToString() = " +
|| Thread.CurrentThread.GetHashCode().ToString());
|| }
|| }
|| }
|| }
||
|| public class innerClass2 {
|| public Thread t = null;
|| public void startme() {
|| t = new Thread(new ThreadStart(threadMain));
|| t.Start();
|| }
|| public void threadMain() {
|| while (true) {
|| innerClass1 l = new innerClass1();
|| l.foo();
|| }
|| }
|| }
|| }
|| }

Well, you are wrong :-).
1. Each thread creates an instance of innerClass1 and foo() puts a lock on
Click to expand...
the object refered to by alock, but as this object is not
shared every thread is free to enter foo().
2. Otherwise, str is a shared object reference (static) and not protected
Click to expand...
by a lock so each thread running foo() is free to toy with
str.....
3. Now if you would synchronize access to str, running foo() in such a
Click to expand...
closed loop allmost prevents other threads to run at the end
 
Thanks for the explanation. It is very interesting to get such a low-level
understanding of what's going on in the processor. BTW, is it a bad thing
for the threads to run much longer then their quantum?

Willy Denoyette said:
pokémon wrote:
|| You are right! I added the static modifier to alock and now it is
|| synchronized.
||
|| But, can you please explain 3) below. I don't understand.
||
||
|| ||| 3. Now if you would synchronize access to str, running foo() in
||| such a
|| closed loop allmost prevents other threads to run at the end
||| of the running threads quota.
|||
||| Willy.

Each thread in the Windows system is allowed to run for an amount of time,
Click to expand...
called a quantum (quantum's can vary per thread and OS
versions), before Windows interrupts the thread to see whether another
Click to expand...
thread (with higher or equal priority) is ready to run.
Now if you take a look at your code, you have 3 runable threads (I don't
Click to expand...
consider the other threads in the process). While one
thread is running the others are ready to run, but the running thread will
Click to expand...
run a large amount of it's quantum while holding a shared
lock (running foo()) as such preventing the other two threads to run when
Click to expand...
scheduled (at the end of the running threads quantum) when
the lock is still held (during foo()). The net result is that each thread
Click to expand...
will run for a much longer time than it's quantum (seconds
 
Back
Top