Hypothetical threading situation

[TDC]

Here a classic "DON'T DO THIS" example:

Public Class Test

Private m_ThreadBDone As Boolean

Sub LaunchThreadAndWait() '<--- called by thread A

Dim theadB as New Thread(Addressof(ThreadBProc))
theadB.Start()

While Not m_ThreadBDone
Sleep(250)
Loop

'at this point thread b is done

End Sub

Sub ThreadBProc
'do some long work
m_ThreadBDone = True
End Sub

End Class

Thread A loop waiting for the boolean m_ThreadBDone to change will not
necassarily see m_ThreadBDone become True because of memory caching.

(And no, I don't need to know how to solve that. I've got that well in
hand).

Given the first example, why isn't this classic threaded worker a
problem?

Public Class SecondTest

Sub LaunchThread() '<--- called by thread A

dim worker as new ThreadedWorker(SomeData)
Dim theadB as New Thread(Addressof(worker.DoWorkProc))
theadB.Start()

'whatever, do other stuff

End Sub

End Class

Public Class ThreadedWorker

m_SomeData

Public Sub New(SomeData) '<--- called by thread A
m_SomeData = SomeData
End Sub

Public Sub DoWorkProc() '<--- called by thread B
do work using m_SomeData
End Sub

End Class

In this example, the SomeData is only used by the threaded worker so
at first glance there is no contention. But since there is no
syncronization, couldn't the m_SomeData variable still be null due to
the same thread caching problem as the first one?

All of this memory caching/ memory barrier stuff is wild...

Tom

 

[Brian Gideon]

Tom,

It's a good question that most people don't think to ask. Starting a
thread implicitly creates a memory barrier. In other words, writes
cannot move past the call to threadB.Start().

Yes, threading, volatility, memory barriers, etc. are very difficult to
grasp.

Brian

 

[TDC]

First, thanks very much for the answer.

Second, where can I look that up (well not that question specifically,
but more like it) so that I don't have to post questions to the
newsgroups on this stuff?

Third, what if the thread is aleady running? For example, the thread
pool threads are already running so if my worker example used the
threadpool, would I then be subject to that problem?

If so, it seems like you'd be forced to perform a lock (or synclock in
VB) in the constructor and then again when the threadproc accesses the
data. Though I suppose you wouldn't need to lock on all the work data
accessed since from that point forward only one thread uses the data.

Anyway, thanks and I eagerly await more information,
Tom

 

[Brian Gideon]

Inline.

First, thanks very much for the answer.

Second, where can I look that up (well not that question specifically,
but more like it) so that I don't have to post questions to the
newsgroups on this stuff?

I recommend reading the following multipage article on threading. The
author talks about memory barriers in page 6. Also, page 17 contains
an excellent list of other resources.

<http://www.yoda.arachsys.com/csharp/threads/index.shtml>

Also, there are a few brilliant minds, including the author of
aforementioned article, that answer these kinds of questions on a
regular basis in the microsoft.public.dotnet.general and
microsoft.public.dotnet.languages.csharp groups. I humbly admit that
I'm not one of them.

Third, what if the thread is aleady running? For example, the thread
pool threads are already running so if my worker example used the
threadpool, would I then be subject to that problem?

You may have an issue if the thread is already running. Though, in the
case of the ThreadPool, I wouldn't be surprised if the
QueueUserWorkItem method creates a memory barrier as well. If it
doesn't then there are a lot of wrong examples out there.

If so, it seems like you'd be forced to perform a lock (or synclock in
VB) in the constructor and then again when the threadproc accesses the
data. Though I suppose you wouldn't need to lock on all the work data
accessed since from that point forward only one thread uses the data.

Yes, you are correct.