determining which core a thread is on

[Lee Crabtree]

Is there any way to find out on which core of a multi-core machine a
thread is executing?

Here's the rationale behind such a question. Maybe it's wrong, I'm not
sure. The app we've written communicates with some USB devices through
a wrapped DLL that SHOULD handle thread safety (locking and suchlike).
However, we've had some very strange, sporadic, and unpredictable bugs,
and one of the places we decided to look first was the multithreaded
areas, as that's a pretty common place for things to blow up unexpectedly.

Here's where the speculation occurs.

After some research, I discovered that the lock keyword (and by
association, the Monitor class) does NOT apply across processes. My
theory, then, is that a thread running on a different core might not be
locking like we think it should. The fix for that would be to use a
Mutex object or switch to a message/response queue system instead of
using the lock keyword, but before I go in and start replacing things,
I'd like to find out if my theory holds any water.

DC

 

[Jon Skeet [C# MVP]]

Is there any way to find out on which core of a multi-core machine a
thread is executing?

Here's the rationale behind such a question. Maybe it's wrong, I'm not
sure. The app we've written communicates with some USB devices through
a wrapped DLL that SHOULD handle thread safety (locking and suchlike).
However, we've had some very strange, sporadic, and unpredictable bugs,
and one of the places we decided to look first was the multithreaded
areas, as that's a pretty common place for things to blow up unexpectedly.

Here's where the speculation occurs.

After some research, I discovered that the lock keyword (and by
association, the Monitor class) does NOT apply across processes.

It certainly doesn't.

My theory, then, is that a thread running on a different core might not be
locking like we think it should.

Um, processes and cores are entirely separate beasts. You could have
two processes both running on the same core, or one process with
multiple threads on different cores.

Do you actually have multiple processes running?

Jon

 

[Nicholas Paldino [.NET/C# MVP]]

Lee,

The lock keyword really compiles to a call to the static Enter method on
the Monitor class, which locks a section of code only for the current
application domain.

So yes, you are right, you should be using a different synchronization
method to block out access to the wrapped DLL. However, I don't think that
you want to use a Mutex, as you could let more than one thread in at a time
to use the wrapped DLL. You will want to use an AutoResetEvent in this
case.

In your wrapper module, you would open an existing AutoResetEvent. If
that doesn't succeed (since it doesn't exist), you would create a new one.
The AutoResetEvent would have a unique name (it should be based on the fully
qualified assembly name, or something very unique). If you create a new
event, then you should call Set on it automatically, if you succeed in
opening an existing one, then don't do anything.

Then, in the method which wraps the call to the dll, you would call
WaitOne on the static event. After the call to the dll expires, you would
call Set again on the AutoResetEvent. This will allow only ONE waiting
thread to proceeed (which is what you want).

Now, whether or not this will solve your problem, I don't know, but it
will guarantee that a call to this method occurs only once across all
processes on your machine.

 

[Lee Crabtree]

No, it's all one process, but it runs on multiple cores. I know that
threads and processes aren't the same thing, but since I'm not totally
clear on how multiple cores changes things, I thought it best to ask.
I'm not an extremely low-level programmer, so the intricacies of stack
creation and inter-thread communication are a closed routine to me.

DC

 

[Jon Skeet [C# MVP]]

No, it's all one process, but it runs on multiple cores.

In that case lock statements will work fine, when used correctly. No
need to go for cross-process options.

Jon

 

[Nicholas Paldino [.NET/C# MVP]]

More than likely, for the OP, the lock statements will work fine, but in
the off chance that there are multiple app domains in the same process, the
lock statement won't work, and you need to use something like an
AutoResetEvent. I highly doubt that is the case here, though.

 

[Lee Crabtree]

Under what circumstances is another ApplicationDomain created? I don't
create any explicitly in my code, but that doesn't mean things aren't
happening behind the scenes.

DC

 

[Nicholas Paldino [.NET/C# MVP]]

Lee,

If you are not creating application domains specifically, then the only
way that a new application domain can be started up is through a library you
are calling. You will have another application domain started up in the
same process more than likely in the case where you have some sort of plugin
architecture and are sandboxing the plugin.

 

[Willy Denoyette [MVP]]

Is there any way to find out on which core of a multi-core machine a
thread is executing?

Here's the rationale behind such a question. Maybe it's wrong, I'm not
sure. The app we've written communicates with some USB devices through a
wrapped DLL that SHOULD handle thread safety (locking and suchlike).
However, we've had some very strange, sporadic, and unpredictable bugs,
and one of the places we decided to look first was the multithreaded
areas, as that's a pretty common place for things to blow up unexpectedly.

Here's where the speculation occurs.

After some research, I discovered that the lock keyword (and by
association, the Monitor class) does NOT apply across processes. My
theory, then, is that a thread running on a different core might not be
locking like we think it should. The fix for that would be to use a Mutex
object or switch to a message/response queue system instead of using the
lock keyword, but before I go in and start replacing things, I'd like to
find out if my theory holds any water.

DC

Adding to what others have said.
You have an application that calls into a *device* via a wrapped DLL, right?
The wrapper DLL does calls into a device driver, that means that no code
path leaves the current process, or am I missing something?

Willy.

 

[Lee Crabtree]

The wrapper actually calls into an unmanaged DLL that we don't control.
All of my locking and synchronization happens above that level, though.

DC

 

[Willy Denoyette [MVP]]

The wrapper actually calls into an unmanaged DLL that we don't control.
All of my locking and synchronization happens above that level, though.

But this DLL is loaded in the current process, no other *process* is
involved here, unless the DLL creates another process.
Normally such a DLL should take care about it's own thread
safety/synchronization, it should clearly document the users requirements or
else it should say it's not thread safe.


Willy.