I'm learning the Task Parallel Library (in conjunction with C# 5.0 async/await), and I want to do something like this:
public class Foo
{
public void UnblockDoSomething()
{
DoWork();
// notify DoSomethingAsync
}
public async Task DoSomethingAsync()
{
DoSomeWork();
await ... // Wait until UnblockDoSomething is called
DoMoreWork();
}
}
In a traditional threaded model, I can accomplish this using condition variables. What is the TPL solution to this problem?
If you just have a one-at-a-time notification, you can use TaskCompletionSource:
public class Foo
{
private TaskCompletionSource<object> _signal = new TaskCompletionSource<object>();
public void UnblockDoSomething()
{
DoWork();
_signal.SetResult(null);
_signal = new TaskCompletionSource<object>();
}
public async Task DoSomethingAsync()
{
var continueSignal = _signal.Task;
DoSomeWork();
await continueSignal;
DoMoreWork();
}
}
Another option is to use a semaphore (SemaphoreSlim), which will "remember" if it's been signalled previously:
public class Foo
{
private readonly SemaphoreSlim _mutex = new SemaphoreSlim(0);
public void UnblockDoSomething()
{
DoWork();
_mutex.Release();
}
public async Task DoSomethingAsync()
{
DoSomeWork();
await _mutex.WaitAsync();
DoMoreWork();
}
}
If you truly need a condition variable, you can use AsyncConditionVariable from my AsyncEx library:
public class Foo
{
private readonly AsyncLock _mutex = new AsyncLock();
private readonly AsyncConditionVariable _cv = new AsyncConditionVariable(_mutex);
public void UnblockDoSomething()
{
using (await _mutex.LockAsync())
{
DoWork();
_cv.Notify();
}
}
public async Task DoSomethingAsync()
{
using (await _mutex.LockAsync())
{
DoSomeWork();
await _cv.WaitAsync();
DoMoreWork();
}
}
}
Related
I want to register consumer by interface, send message, initialize it by interface from container, then consume:
public sealed class TestConsumer<T> : IConsumer<T>
where T : class
{
private readonly Func<ConsumeContext<T>, Task> _onConsume;
private readonly EventWaitHandle _handle;
public TestConsumer(Func<ConsumeContext<T>, Task> onConsume)
{
_onConsume = onConsume;
_handle = new EventWaitHandle(false, EventResetMode.ManualReset);
}
public async Task Consume(ConsumeContext<T> context)
{
try
{
await _onConsume(context).ConfigureAwait(false);
}
finally
{
_handle.Set();
}
}
public async Task GetTask()
{
while (!_handle.WaitOne(0))
await Task.Delay(100);
}
}
public class MyRequest { }
[TestFixture]
public class ConsumerTests
{
[Test]
public async Task Test()
{
var services = new ServiceCollection();
var tc = new TestConsumer<MyRequest>(async (c) => Console.WriteLine("request"));
services.AddSingleton<IConsumer<MyRequest>>(tc);
services.AddSingleton<IBusControl>(x => Bus.Factory.CreateUsingInMemory(cfg =>
{
cfg.ReceiveEndpoint("foobar", c => { c.Consumer<IConsumer<MyRequest>>(x); });
}));
var sp = services.BuildServiceProvider();
await sp.GetRequiredService<IBusControl>().StartAsync();
//and how do I send it?
//this will obviously not work with Uri!!!
var sendEndpoint = await sp.GetRequiredService<IBusControl>().GetSendEndpoint(new Uri("foobar", UriKind.Relative));
await sendEndpoint.Send(new MyRequest());
await tc.GetTask();
Console.WriteLine("done");
}
}
Honestly, lack of documentation is driving me crazy. There is such thing as harness, but it works only if you throw your DI container into garbage can or write a ton of adapters.
How do one can use InMemory and combine it to completely uncompatible Uri in Send method?
I need to spawn multiple tasks having in mind that I could add more tasks through a SignalR hub later on. Those tasks should be named, so I can search for a specific task. Each of these tasks should be able to be canceled independently (separate CancellationTokenSource).
Questions:
Is there a different collection that I can use?
Can I improve my code in any way?
public interface IMyClass
{
void Start(string name);
void Stop(string name);
}
public class MyClass : IMyClass
{
private List<Tuple<string, Task, CancellationTokenSource>> _tasks = new List<Tuple<string, Task, CancellationTokenSource>>();
public void Start(string name)
{
CancellationTokenSource cts = new CancellationTokenSource();
Task task = Task.Factory.StartNew(() => DoWork(name, cts.Token));
_tasks.Add(new Tuple<string, Task, CancellationTokenSource>(name, task, cts));
}
public void Stop(string name)
{
foreach (var tuple in _tasks)
{
if (tuple.Item1.Contains(name))
{
CancellationTokenSource cts = tuple.Item3;
cts.Cancel();
}
}
}
public void DoWork(string name, CancellationToken token)
{
try
{
while (true)
{
Console.WriteLine($"{name} is working");
// long operation...
Thread.Sleep(1000);
if (token.IsCancellationRequested)
{
Console.WriteLine($"{name} canceled");
token.ThrowIfCancellationRequested();
}
}
}
catch (OperationCanceledException ex)
{
Console.WriteLine(ex.Message);
}
}
}
I think it looks fine, but you may consider if it is allowed to use the same task name twice.
And instead of
private List<Tuple<string, Task, CancellationTokenSource>> _tasks = new List<Tuple<string, Task, CancellationTokenSource>>();
you could use a dictionary
private Dictionary<string,Tuple<Task, CancellationTokenSource>> _tasks = new Dictionary<string,Tuple<Task, CancellationTokenSource>>();
I would personally wrap the information about the task in a new type, that makes it easier to maintain and add new features later. Something like this:
public class TaskInfo
{
public string Name { get; set; }
public Task Task { get; set; }
public CancellationTokenSource Token { get; set; }
}
// Define other methods and classes here
public interface IMyClass
{
void Start(string name);
void Stop(string name);
}
public class MyClass : IMyClass
{
private Dictionary<string,TaskInfo> _tasks = new Dictionary<string,TaskInfo>();
public void Start(string name)
{
if(_tasks.ContainsKey(name))
throw new Exception($"Task with name {name} already exists");
CancellationTokenSource cts = new CancellationTokenSource();
TaskInfo taskInfo = new TaskInfo() {
Token = cts,
Name = name,
Task = Task.Factory.StartNew(() => DoWork(name, cts.Token))
};
_tasks.Add(name,taskInfo);
}
public void Stop(string name)
{
if (_tasks.ContainsKey(name)) {
_tasks[name].Token.Cancel();
}
}
public void DoWork(string name, CancellationToken token)
{
try
{
while (true)
{
Console.WriteLine($"{name} is working");
// long operation...
Thread.Sleep(1000);
if (token.IsCancellationRequested)
{
Console.WriteLine($"{name} canceled");
token.ThrowIfCancellationRequested();
}
}
}
catch (OperationCanceledException ex)
{
Console.WriteLine(ex.Message);
}
}
}
this may not be a better solution, but i prefer an approach like this
I try to wait for the class to be finished with instantiate.
My architecture is the following. Cook is inheriade from CookChief.
And if I instantiate cook, CookChief is creating himself, but CookChief is calling 1 other class named Cookhelper the cookhelper is waiting for a input and for this input method i want to wait in Cook.
The thing is iam creating this in MVVM Galasoft and my entry point is the CookViewmodel, with a relaycommand.
In the code below you can see my architecture. To say it short I want to wait until this bool processed = await Task.Run(() => ValidateForDeviceId()); is finished.
My first step was to outsource the constructer of each class. And create a init method.
This is my code:
public CookViewModel()
{
startCookButtonCommand = new RelayCommand(Cook);
}
private async Task Cook()
{
cook.Init();
}
public class Cook : CookChief
{
public Cook()
{
}
public async Task Init()
{
await this.CookChiefInit();
//here I want to wait until CookChiefInit is finished
Cooking();
}
public void Cooking()
{
MessageBox.Show("Input received");
}
}
Now the Cookchief:
public Cookchief()
{
}
protected async Task CookchiefInit()
{
this.Cookhelper = new Cookhelper();
Cookhelper.CookHelperInit();
}
And in the CookHelper we do this:
public CookHelper()
{
}
public void CookHelperInit()
{
this.driverWindow = new DriverWindow();
startProc();
}
private async void startProc()
{
ShowOrCloseDriverWindow(true);
//this is the task what we wait for before we can repeat
bool processed = await Task.Run(() => ValidateForDeviceId());
if(processed)
{
ShowOrCloseDriverWindow(false);
}
else
{
MessageBox.Show("DriverError");
}
}
private bool ValidateForDeviceId()
{
for (; ; )
{
this.deviceId = Input.deviceId;
if (deviceId > 0)
{
break;
}
}
return true;
}
Per the discussion in the comments, the problem here was that the initialization routine mixed synchronous and asynchronous methods and calls. Additionally, some async methods were called without the await keyword. The solution was to make all calls asynchronous and await them.
cook.Init() needs an await:
private async Task Cook()
{
await cook.Init();
}
In CookchiefInit(), the CookHelperInit() call needs to be awaited:
protected async Task CookchiefInit()
{
this.Cookhelper = new Cookhelper();
Cookhelper.CookHelperInit();
}
In order to await CookHelperInit(), it needs to be made asynchronous. The startProc() call is to an async method, so it must also be awaited:
public async Task CookHelperInit()
{
this.driverWindow = new DriverWindow();
await startProc();
}
I have a code block which is eventually accessed by multiple threads. I search for an up to date async mechanism to continue executing when all threads have passed.
Currently I do the following with a CountDownEvent which works just fine (without async support).
public class Watcher
{
private static readonly Logger Log = LogManager.GetCurrentClassLogger();
private readonly CountdownEvent _isUpdating = new CountdownEvent(1);
private readonly IActivity _activity;
public Watcher([NotNull] IActivity activity)
{
_activity = activity ?? throw new ArgumentNullException(nameof(activity));
_activity.Received += OnReceived;
}
private void OnReceived(IReadOnlyCollection<Summary> summaries)
{
_isUpdating.AddCount();
try
{
// Threads processing
}
finally
{
_isUpdating.Signal();
}
}
private void Disable()
{
_activity.Received -= OnReceived;
_isUpdating.Signal();
/* await */ _isUpdating.Wait();
}
}
Do I need to use any of those AsyncCountdownEvent implementations or is there any other built-in mechanism? I already thought about using a BufferBlock because it has async functionality but I think it's a bit overkill.
Additional to the comments:
IActivity is a WebService call (but shouldn't effect the implementation on top or vice versa)
public async Task Start(bool alwayRetry = true, CancellationToken cancellationToken = new CancellationToken())
{
var milliseconds = ReloadSeconds * 1000;
do
{
try
{
var summaries = await PublicAPI.GetSummariesAsync(cancellationToken).ConfigureAwait(false);
OnSummariesReceived(summaries);
}
catch (Exception ex)
{
Log.Error(ex.Message);
OnErrorOccurred(ex);
}
await Task.Delay(milliseconds, cancellationToken).ConfigureAwait(false);
// ReSharper disable once LoopVariableIsNeverChangedInsideLoop
} while (alwayRetry);
}
It's not clear the IActivity signatures; but you can wait for a range of tasks to be completed:
class MultiAsyncTest {
Task SomeAsync1() { return Task.Delay(1000); }
Task SomeAsync2() { return Task.Delay(2000);}
Task EntryPointAsync() {
var tasks = new List<Task>();
tasks.Add(SomeAsync1());
tasks.Add(SomeAsync2());
return Task.WhenAll(tasks);
}
}
What's IActivity's signature? Does it support Task? Or you are using Thread? More explanation would help to a more specified answer.
My app needs to load plugins into separate app domains and then execute some code inside of them asynchronously. I've written some code to wrap Task in marshallable types:
static class RemoteTask
{
public static async Task<T> ClientComplete<T>(RemoteTask<T> remoteTask,
CancellationToken cancellationToken)
{
T result;
using (cancellationToken.Register(remoteTask.Cancel))
{
RemoteTaskCompletionSource<T> tcs = new RemoteTaskCompletionSource<T>();
remoteTask.Complete(tcs);
result = await tcs.Task;
}
await Task.Yield(); // HACK!!
return result;
}
public static RemoteTask<T> ServerStart<T>(Func<CancellationToken, Task<T>> func)
{
return new RemoteTask<T>(func);
}
}
class RemoteTask<T> : MarshalByRefObject
{
readonly CancellationTokenSource cts = new CancellationTokenSource();
readonly Task<T> task;
internal RemoteTask(Func<CancellationToken, Task<T>> starter)
{
this.task = starter(cts.Token);
}
internal void Complete(RemoteTaskCompletionSource<T> tcs)
{
task.ContinueWith(t =>
{
if (t.IsFaulted)
{
tcs.TrySetException(t.Exception);
}
else if (t.IsCanceled)
{
tcs.TrySetCancelled();
}
else
{
tcs.TrySetResult(t.Result);
}
}, TaskContinuationOptions.ExecuteSynchronously);
}
internal void Cancel()
{
cts.Cancel();
}
}
class RemoteTaskCompletionSource<T> : MarshalByRefObject
{
readonly TaskCompletionSource<T> tcs = new TaskCompletionSource<T>();
public bool TrySetResult(T result) { return tcs.TrySetResult(result); }
public bool TrySetCancelled() { return tcs.TrySetCanceled(); }
public bool TrySetException(Exception ex) { return tcs.TrySetException(ex); }
public Task<T> Task
{
get
{
return tcs.Task;
}
}
}
It's used like:
sealed class ControllerAppDomain
{
PluginAppDomain plugin;
public Task<int> SomethingAsync()
{
return RemoteTask.ClientComplete(plugin.SomethingAsync(), CancellationToken.None);
}
}
sealed class PluginAppDomain : MarshalByRefObject
{
public RemoteTask<int> SomethingAsync()
{
return RemoteTask.ServerStart(async cts =>
{
cts.ThrowIfCancellationRequested();
return 1;
});
}
}
But I've run into a snag. If you look in ClientComplete, there's a Task.Yield() I've inserted. If I comment this line, ClientComplete will never return. Any ideas?
My best guess is that you are facing these issues because of the async method that contains await and this is managed via the ThreadPool which can allocate some recycled Thread.
Reference
Best practice to call ConfigureAwait for all server-side code
Actually, just doing an await can do that(put you on a different thread). Once your async method hits
an await, the method is blocked but the thread returns to the thread
pool. When the method is ready to continue, any thread is snatched
from the thread pool and used to resume the method.
Try to streamline the code, generate threads for baseline cases and
performance is last.