Any implicit MemoryBarrier on EventWaitHandle methods?

T

TDC

I've frequently coded something along the lines of this (with stuff
like Dispose ommited for clarity):

================================================

class SomeBackgroundOp
{

// background args
private string _x;
private object _y;
private long _z;

// background results
private volatile DateTime _a
private volatile double _b;
private volatile object _c;

// thread control
private Thread _task;
private ManualResetEvent _completedSignal;
private volatile bool _completed;

public bool DoSomething(string x, object y, long z, int
initialWaitMs)
{
bool doneWithinWait;

_x = x;
_y = y;
_z = z;

_completedSignal = new ManualResetEvent(false);

_task = new Thread(new ThreadStart(Task));
_task.IsBackground = true;
_task.Start()

doneWithinWait = _completedSignal.WaitOne(initialWaitMs);

return doneWithinWait;

}

public bool Completed
{
get
{
return _completed;
}
}

/* public getters for the result fields go here, with an excepting
thrown
if _completed is not true; */

private void Task()
{
// args x, y, and z are written once, before the Thread.Start
// implicit memory barrier so they may be accessed freely.

// possibly long-running work goes here

// with the work completed, assign the result fields _a, _b, _c
here
_completed = true;
_completedSignal.Set();

}
}

================================================

So my question is, are the volatiles needed as shown? Or does the
ManualResetEvent.Set have an implicit memory barrier as I've read
Thread.Start does? Or would an explicit MemoryBarrier call be ebtter
than the volatiles?

Thanks,
Tom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top