Cancellation of a Task without Providing the Task method with the CancellationTokenSource

I'm trying to provide a functionality of having two Methods one called StartTask(action mymethod) and the other called StopTask();

problem is the action has to have access to the CancellationTokenSource to check for cancellation and exit the method (return) which is not really what i want the method could be in another component or layer , i cant push every Method to have access to that cancellationtokensource,

i cant push the designer/developer of the component which have the process method to check for cancellation and return.

is there is any way to have something like this , i know it sound strange and inapplicable , just thought of asking.

this is the best i got:

       CancellationTokenSource cancellationTokenSource;
    private void button1_Click(object sender, EventArgs e)
    {
        cancellationTokenSource = new CancellationTokenSource();
        Task t = new Task(() => Dowork(CancellationAction), cancellationTokenSource.Token, TaskCreationOptions.LongRunning);
        t.Start();
    }
    private bool CancellationAction()
    {

        if (cancellationTokenSource.IsCancellationRequested)
        {
            label1.Invoke(new MethodInvoker(() =>
                                                {
                                                    label1.Text = "Cancellation Requested!";
                                                }));
            return true;
        }
        return false;
    }
    private void Dowork(Func<bool> Return)
    {
        int x = 1;
        while (true)
        {
            x++;
            label1.Invoke(new MethodInvoker(() =>
                                                {
                                                    label1.Text = x.ToString();
                                                }));
            Thread.Sleep(1000);
            if (Return())
            {
                return;
            }
        }
    }

problem with this is DoWork now has to have one parameter which is func , but what if the method already takes other parameters ? the creation of task will be in a开发者_JAVA百科nother class which might not have any idea what parameters to pass beside CancellationAction

If the component does not provide a way to cancel one of its running tasks, then the caller should not be able to cancel it. It could leave the application/database/anything in an unknown state.

So basically the lower level component should provide the caller with a way to cancel a task (ManualResetEvent, CancelAsync method like the BackgroundWorker, etc.). Otherwise the caller should wait for it to finish.

If the lower level component does not provide such a feature, it is most of the time considered as bad design.

I'm not sure that I entirely understand your question, but I'll take a stab at it. It seems like you're trying to solve two problems at once here.

First you're trying to pass parameters to an asynchronous thread and/or cancel that thread (very similar issues). As others have stated BackgroundWorker already handles canceling. That implementation is similar to passing any argument to your thread. If I were replicating that functionality for instance I'd add a Cancel property or method to my worker thread that any other component could call and check a backing value in my main thread loop. No reason to do that for canceling threads these days, just an example of passing and using values to a worker thread.

The other problem that it looks like you need to solve is how to send messages between different parts of your application that shouldn't otherwise need to reference each other. Typically I've seen this done with a service provider of some sort. Implement an interface on a context or common model that all components receive an instance of or have easy access to. The interface should contain any events, methods and properties so the different components can communicate.

E.g. (probably a bad example but...) If my grammar checking routine should cancel when a document is closed, I would define a DocumentClosing event and OnDocumentClosing method on an IDocumentService interface and implement that interface in an appropriate context/model. When creating my document viewer UI component and grammar checker thread component I would inject an instance of the context/model typed as the interface. When the document viewer starts to close the document, it calls the OnDocumentClosing method from the interface. When the thread is created it would attach to the DocumentClosing event and if the event fires a flag is set. Then at intervals while checking grammar, I would check the flag and cancel as appropriate.

This sort of implementation gives you the flexibility to have any component trigger appropriate events and any other component react to them regardless of where in your application the components are used. In fact, this approach is useful even in synchronous situations such as menu items changing state in response to application events. It allows for easy unit testing of all your components. And the segregation of responsibility means that you can easily change any of the trigger points and responses as needed.

Why don't you use BackgroundWorkerThread or other threading mechanism? Is there a particular reason for using Task Parallel Library?

BackgroundWorkerThread will give you a change to cancel the task and then respond to cancellation.