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

[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();
}
}
}
}
}

 

[pokémon]

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.

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

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

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

closed loop allmost prevents other threads to run at the end

 

[pokémon]

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?

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,

called a quantum (quantum's can vary per thread and OS

versions), before Windows interrupts the thread to see whether another

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

consider the other threads in the process). While one

thread is running the others are ready to run, but the running thread will

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

scheduled (at the end of the running threads quantum) when

the lock is still held (during foo()). The net result is that each thread

will run for a much longer time than it's quantum (seconds