a threading test for your use/thoughts on affinity

[not_a_commie]

Here's some code I wrote trying to track down a deadlock bug. I was
unable to make this code deadlock on my Core 2 Duo. I'd be interested,
though, if y'all think it is the right way to use thread affinity or
not. I'd also be interested if you saw any code that might cause a
deadlock in some other scenario.

using System;
using System.Collecti ons.Generic;
using System.Text;
using System.Threadin g;

namespace TestThreading
{
public sealed class Program
{
static private Thread _backgroundThre ad = null;
static private EventWaitHandle _tickCountUpdat eRequest = new
EventWaitHandle (false, EventResetMode. AutoReset);
static private EventWaitHandle _tickCountUpdat eDone = new
EventWaitHandle (false, EventResetMode. AutoReset);
static public long CurrentTickCoun t = 0;
private static void _BackgroundThre adFunc()
{
Thread.BeginThr eadAffinity(); // always read the tick count from
the same CPU -- not necessary in Vista
while (true)
{
_tickCountUpdat eRequest.WaitOn e();
CurrentTickCoun t = System.Diagnost ics.Stopwatch.G etTimestamp();
_tickCountUpdat eDone.Set();
}
Thread.EndThrea dAffinity(); // never called; but here for symmetry
}

static Program() {
_backgroundThre ad = new Thread(new
ThreadStart(_Ba ckgroundThreadF unc));
_backgroundThre ad.IsBackground = true;
_backgroundThre ad.Start();
}

public long GetCount()
{
lock (_backgroundThr ead)
{
Program._tickCo untUpdateReques t.Set();
Program._tickCo untUpdateDone.W aitOne();
return CurrentTickCoun t;
}
}

private static void _GetCountFunc() {
Random r = new Random();
Program p = new Program();
while (true)
{
// sleep a random amount of time then read
Thread.Sleep(r. Next(20));
lock (System.Console .Out)
{
System.Console. Out.WriteLine(" thread " +
Thread.CurrentT hread.ManagedTh readId +
": " + p.GetCount().To String());
}
}
}

static void Main(string[] args)
{
Random r = new Random();
Thread d = new Thread(new ThreadStart(_Ge tCountFunc));
d.Start();
while (true)
{
Thread a = new Thread(new ThreadStart(_Ge tCountFunc));
Thread b = new Thread(new ThreadStart(_Ge tCountFunc));
Thread c = new Thread(new ThreadStart(_Ge tCountFunc));
a.Start();
b.Start();
c.Start();
Thread.Sleep(r. Next(50));
a.Abort();
Thread.Sleep(r. Next(50));
b.Abort();
c.Abort();
}
}
}
}

[Chris Mullins [MVP]]

I have to confess, I'm completly missing what you're trying to accomplish
here.

Why are you trying to accomplish with Begin/EndThreadAffini ty? All this does
is tell the CLR you have affinity for the actualy thread you're scheduled
on.

You really are trying to set PROCESSOR affinity, not Thread Affinity.
Unfortunatly, you're not doing what you think - the O/S Thread Scheduler may
still schedule your thread on either of the Cores on your system.

Duffy has a recent blog entry where he's using processor affinity for some
tricks - you can just copy what he does...
http://www.bluebytesoftware.com/blog...9a3980e6d.aspx

As for deadlocks - yes, your code is susceptable to them. You're aborting
threads that may be inside a lock at the time of the abort. This is a very
bad practice...

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** *************@o 5g2000hsb.googl egroups.com...

Here's some code I wrote trying to track down a deadlock bug. I was
unable to make this code deadlock on my Core 2 Duo. I'd be interested,
though, if y'all think it is the right way to use thread affinity or
not. I'd also be interested if you saw any code that might cause a
deadlock in some other scenario.

using System;
using System.Collecti ons.Generic;
using System.Text;
using System.Threadin g;

namespace TestThreading
{
public sealed class Program
{
static private Thread _backgroundThre ad = null;
static private EventWaitHandle _tickCountUpdat eRequest = new
EventWaitHandle (false, EventResetMode. AutoReset);
static private EventWaitHandle _tickCountUpdat eDone = new
EventWaitHandle (false, EventResetMode. AutoReset);
static public long CurrentTickCoun t = 0;
private static void _BackgroundThre adFunc()
{
Thread.BeginThr eadAffinity(); // always read the tick count from
the same CPU -- not necessary in Vista
while (true)
{
_tickCountUpdat eRequest.WaitOn e();
CurrentTickCoun t = System.Diagnost ics.Stopwatch.G etTimestamp();
_tickCountUpdat eDone.Set();
}
Thread.EndThrea dAffinity(); // never called; but here for symmetry
}

static Program() {
_backgroundThre ad = new Thread(new
ThreadStart(_Ba ckgroundThreadF unc));
_backgroundThre ad.IsBackground = true;
_backgroundThre ad.Start();
}

public long GetCount()
{
lock (_backgroundThr ead)
{
Program._tickCo untUpdateReques t.Set();
Program._tickCo untUpdateDone.W aitOne();
return CurrentTickCoun t;
}
}

private static void _GetCountFunc() {
Random r = new Random();
Program p = new Program();
while (true)
{
// sleep a random amount of time then read
Thread.Sleep(r. Next(20));
lock (System.Console .Out)
{
System.Console. Out.WriteLine(" thread " +
Thread.CurrentT hread.ManagedTh readId +
": " + p.GetCount().To String());
}
}
}

static void Main(string[] args)
{
Random r = new Random();
Thread d = new Thread(new ThreadStart(_Ge tCountFunc));
d.Start();
while (true)
{
Thread a = new Thread(new ThreadStart(_Ge tCountFunc));
Thread b = new Thread(new ThreadStart(_Ge tCountFunc));
Thread c = new Thread(new ThreadStart(_Ge tCountFunc));
a.Start();
b.Start();
c.Start();
Thread.Sleep(r. Next(50));
a.Abort();
Thread.Sleep(r. Next(50));
b.Abort();
c.Abort();
}
}
}
}

[Chris Mullins [MVP]]

I really need to edit my posts before sending them out. I've got duplicate
sentences and everything in there. Sorry about that...

The conclusion is the same though - you're not setting processor affinity
(which is what you're trying to accomplish), but are rather setting affinity
of the Managed Thread to the O/S thread.

This means your thread can still be scheduled on either processing core,
depending on the circumstances.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Chris Mullins [MVP]" <cm******@yahoo .comwrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

>I have to confess, I'm completly missing what you're trying to accomplish
here.

Why are you trying to accomplish with Begin/EndThreadAffini ty? All this
does is tell the CLR you have affinity for the actualy thread you're
scheduled on.

You really are trying to set PROCESSOR affinity, not Thread Affinity.
Unfortunatly, you're not doing what you think - the O/S Thread Scheduler
may still schedule your thread on either of the Cores on your system.

Duffy has a recent blog entry where he's using processor affinity for some
tricks - you can just copy what he does...
http://www.bluebytesoftware.com/blog...9a3980e6d.aspx

As for deadlocks - yes, your code is susceptable to them. You're aborting
threads that may be inside a lock at the time of the abort. This is a very
bad practice...

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** *************@o 5g2000hsb.googl egroups.com...

>Here's some code I wrote trying to track down a deadlock bug. I was
unable to make this code deadlock on my Core 2 Duo. I'd be interested,
though, if y'all think it is the right way to use thread affinity or
not. I'd also be interested if you saw any code that might cause a
deadlock in some other scenario.

using System;
using System.Collecti ons.Generic;
using System.Text;
using System.Threadin g;

namespace TestThreading
{
public sealed class Program
{
static private Thread _backgroundThre ad = null;
static private EventWaitHandle _tickCountUpdat eRequest = new
EventWaitHandl e(false, EventResetMode. AutoReset);
static private EventWaitHandle _tickCountUpdat eDone = new
EventWaitHandl e(false, EventResetMode. AutoReset);
static public long CurrentTickCoun t = 0;
private static void _BackgroundThre adFunc()
{
Thread.BeginTh readAffinity(); // always read the tick count from
the same CPU -- not necessary in Vista
while (true)
{
_tickCountUpda teRequest.WaitO ne();
CurrentTickCou nt = System.Diagnost ics.Stopwatch.G etTimestamp();
_tickCountUpda teDone.Set();
}
Thread.EndThre adAffinity(); // never called; but here for symmetry
}

static Program() {
_backgroundThr ead = new Thread(new
ThreadStart(_B ackgroundThread Func));
_backgroundThr ead.IsBackgroun d = true;
_backgroundThr ead.Start();
}

public long GetCount()
{
lock (_backgroundThr ead)
{
Program._tickC ountUpdateReque st.Set();
Program._tickC ountUpdateDone. WaitOne();
return CurrentTickCoun t;
}
}

private static void _GetCountFunc() {
Random r = new Random();
Program p = new Program();
while (true)
{
// sleep a random amount of time then read
Thread.Sleep(r .Next(20));
lock (System.Console .Out)
{
System.Console .Out.WriteLine( "thread " +
Thread.Current Thread.ManagedT hreadId +
": " + p.GetCount().To String());
}
}
}

static void Main(string[] args)
{
Random r = new Random();
Thread d = new Thread(new ThreadStart(_Ge tCountFunc));
d.Start();
while (true)
{
Thread a = new Thread(new ThreadStart(_Ge tCountFunc));
Thread b = new Thread(new ThreadStart(_Ge tCountFunc));
Thread c = new Thread(new ThreadStart(_Ge tCountFunc));
a.Start();
b.Start();
c.Start();
Thread.Sleep(r .Next(50));
a.Abort();
Thread.Sleep(r .Next(50));
b.Abort();
c.Abort();
}
}
}
}

[not_a_commie]

The conclusion is the same though - you're not setting processor affinity

(which is what you're trying to accomplish), but are rather setting affinity
of the Managed Thread to the O/S thread.

This means your thread can still be scheduled on either processing core,
depending on the circumstances.

I don't really care what processor the background thread runs on. I
just don't want it jumping between two different processors. Will the
OS ever move a thread between processors once it has started running?

Is there a standard way to set processor affinity for threads
in .NET?

My thinking was that an abort would still trigger the "dispose" on the
lock. But I think you're right in saying that it won't. A volatile
flag then seems a better way to do it.

[Chris Mullins [MVP]]

"not_a_comm ie" <no********@gma il.comwrote

>The conclusion is the same though - you're not setting processor affinity
(which is what you're trying to accomplish), but are rather setting
affinity
of the Managed Thread to the O/S thread.

This means your thread can still be scheduled on either processing core,
depending on the circumstances.

I don't really care what processor the background thread runs on. I
just don't want it jumping between two different processors. Will the
OS ever move a thread between processors once it has started running?

From time-slice to time-slice, the O/S can move the thread between
processors. You need to explicitly set processor affinity to prevent that.

Is there a standard way to set processor affinity for threads
in .NET?

Not really. You need to call out to Win32.

The link I sent you, to a Joe Duffy blog entry, shows an example of that
being done.

My thinking was that an abort would still trigger the "dispose" on the
lock. But I think you're right in saying that it won't.

The right answer is to not abort the thread. This will cause you all sorts
of headaches and will never, ever, work perfectly. It's always going to be
prone to bugs. You need a better signaling mechanism.

A volatile flag then seems a better way to do it.

That won't really do it either, and is much more complex than it initially
sounds. Reading and Writing to Volatile variables still needs locks to
insure you don't get read/write tears. There are alot of subtle behaviors
around volatile variables that are best avoided.

If you really need to go down this route, use the various Interlocked
methods, not a volatile variable.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

[Willy Denoyette [MVP]]

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** *************@n 35g2000prd.goog legroups.com...

>The conclusion is the same though - you're not setting processor affinity
(which is what you're trying to accomplish), but are rather setting
affinity
of the Managed Thread to the O/S thread.

This means your thread can still be scheduled on either processing core,
depending on the circumstances.

I don't really care what processor the background thread runs on. I
just don't want it jumping between two different processors. Will the
OS ever move a thread between processors once it has started running?

Is there a standard way to set processor affinity for threads
in .NET?

You can specify the processor you want to run your thread on by setting the
ProcessorAffini ty property of the System.Diagnost ics.ProcessThre ad class,
but this is soemthing you shouldnt do, really, don't assume you can take
over the role of the scheduler for free, he will bite real hard when he
doesn't like what you are doing. Better is to specify the "prefered"
processor for the thread to run on, by sessting the IdealProcessor property
(of the same class) to the processor number you prefer to have your thread
on. Note however that the latter is something that is allready done by the
OS versions starting with XP and up.
Willy.

[Michael D. Ober]

Windows will move a thread between processors if processor affinity is not
set. However, even with processor affinity not set, Windows attempts to
keep a thread on the same processor the entire time it is executable and
still in that processor's L2 cache. If a thread is non-executable for long
enough that it has been flushed from the processor L2 cache, it is eligible
for the first available processor since the cache miss penalty will be
incurred regardless of which processor it is moved to.

Mike Ober.

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** *************@n 35g2000prd.goog legroups.com...

>The conclusion is the same though - you're not setting processor affinity
(which is what you're trying to accomplish), but are rather setting
affinity
of the Managed Thread to the O/S thread.

This means your thread can still be scheduled on either processing core,
depending on the circumstances.

I don't really care what processor the background thread runs on. I
just don't want it jumping between two different processors. Will the
OS ever move a thread between processors once it has started running?

Is there a standard way to set processor affinity for threads
in .NET?

My thinking was that an abort would still trigger the "dispose" on the
lock. But I think you're right in saying that it won't. A volatile
flag then seems a better way to do it.

[not_a_commie]

Thanks, everyone, for the fantastic info on this. Supposedly Vista
synchronizes the different motherboard socket tick counts during boot.
Anybody know if this will be back-ported to WinXP? Anybody know if the
current Linux kernels do this?