I have a third-party object with asynchronous start and stop methods. Each start and stop may fail with exception. The object is not re-entrant, i.e. I can only call its start or stop method after the previous start/stop has completed.
I need to have a class that handles those transitions to the correct (=last asked) state, while minimizing the number of transitions, allowing my client to submit any number of start/stop requests from any thread at any time.
Currently, I’ve implemented that functionality as endless loop in the async method, however It’s too complex, the loop is over 4 pages long, on each iteration I need to manually switch between 8 states (with the following 3 bits: need to be started/stopped, did tried to start/stop, did failed/succeeded). It smells.
I have a feeling I might be missing something obvious here.
And also that my code looks somewhat similar to what compiler does when compiling an async function.
Is there a better way to approach the problem?
Sounds like you need a mutex around the calls. You need to block any other code from calling these methods until the methods return (or signal that they are done).
I would simply wrap the object and add a mutex for the calls. That way you can guarantee that if you don't make two calls at the same time.
You don't need to block on the mutex. You can use something like a producer/consumer queue or a threadpool to synchornize the access.
If you are in a single threaded environment you can also do it with a simple queue (and skip all the multi-threaded objects).
Related
So what I am dealing with here is a pretty complex server application that performs quite a long, complex and lengthy operation involving a number of threads and a number of tasks (yes, some are created as Tasks and some are "manually" created threads.
The complex and lengthy process we are talking here is triggered using a REST API call (assume a web page generates the request object based on user input), and provides the user with an ID to poll for the progress of the operation.
I am looking for an efficient way to allow the user to click an "Abort/Stop" button that will stop this whole orchestra of threads/tasks.
(keep in mind this server can process a number of requests as described above).
I have looked into a number of options, all of which seem to require the threads/tasks themselves to monitor for an "abort flag" during their operation loop and break out of the loop should it be required.
Obviously using Thread.Abort is a big no no.
I have thought about having some kind of an abstract class (say: AbortableThread) all which all my "worker" threads will have to implement, where the only abstract function would be Abort(), so that each thread can end in a clean manner, closing and finishing whatever it needs to.
This way, I would perhaps be able to keep tabs on the threads that have been spawned by a specific user request and just call Abort() in a foreach loop.
Despite that, I still try to figure out how would it be able to break into the loops I run, so my 2nd though would be that this "abstract" class could have a property shouldBreak which will again I will be able to set from "outside", but this then brings me back to (almost) square one where I have to add "logic" into my threads to be able to abort.
A 3rd idea I came up with is to have my logical loops call Abort() on every loop, without any validation whether an abort is currently required or not, where I will check my abstract's base class shouldBreak bool and act accordingly should it be required.
There are no code examples and I have decided I would rather figure this out in high level before I dive into implementation.
Thank you for reading this long question!
I need my code to execute after waiting for a specific time. This should happen asynchronous without blocking my thread. I searched the web and found many ways to do this. Two options are to use the System.Timers or to use RegisterWaitForSingleObject and a ManualResetEvent.
I couldn't really figure out the difference or when to prefer one over the other.
Can you tell me briefly why and when to use Timers or RegisterWaitForSingleObject with ManualResetEvent?
Sidenote: I'm fond of TAP and TPL and generally prefer those over other patterns (but is this the only reason for not using System.Timer?)
Timers
You use Timers when you want the same code to run multiple times, with a specific amount of time in between.
RegisterWaitForSingleObject
The documentation says it best:
Registers a delegate that is waiting for a WaitHandle.
And a WaitHandle is used when you want to
wait for exclusive access to shared resources.
If you're not waiting for shared resources, then it's not appropriate for your use case.
ManualResetEvent
The documentation says
Represents a thread synchronization event that, when signaled, must be reset manually.
The "signalling" and "resetting" are things that your code needs to do. It's used when one of your threads needs to signal to another of your threads that it can continue.
Your use case
You said:
I need my code to execute after waiting for a specific time.
If you do not need to repeat the code over and over, and you aren't waiting for shared resources, and you aren't waiting for another thread, then none of the above methods are appropriate.
If you really just need to wait a specific amount of time before moving on, then, as mentioned already, use Task.Delay:
await Task.Delay(5000); //wait 5 seconds
You use WaitForSingleObject to wait until THE OBJECT is signalled to be in specific state. OR TIMEOUT occurs. So this is not what you want to do. You want your code to be "paused" for a specific amount of time. So "time" here is main result.
I would try to go with await Task.Delay(ms). This looks like the most convinient way to do this nowadays.
I am working on a soloution with lots of projects in it. I have a project that hosts my utility methods. All of the other projects are using this project methods.
I want to know is it ok that a static method gets called from multiple projects maybe at same time?
Also, in one of my methods I have an optional parameter to do a Thread.Sleep() what happens if one project calls this method with sleep and other one with no sleep at the same time?
I am really confused by this structure!
I want to know is it ok that a static method gets called from multiple projects maybe at same time?
Well it depends on what the method does. You need to take responsibility for making sure it's okay to call it from multiple threads at the same time. (Whether the callers are in the same project is almost always completely irrelevant.)
So long as you don't modify any shared state in a dangerous way - e.g. adding to a List<T> without any synchronization - you should be fine. It all depends on what you're doing though.
Each call will be independent in terms of having a separate set of parameters and local variables. Now if some of those parameters refer to objects which are visible to other threads, that's a different matter... but we can't tell that from your question.
Note that the use of Thread.Sleep here is pretty much irrelevant. Admittedly if you have some synchronization (e.g. via lock) then it would be pretty unpleasant for the thread which owns a lock to then sleep...
As the function says, Thread Sleep, the current calling thread will sleep for the duration of the call. If you have several threads calling into this function, they will all sleep. If all your projects are run from the same thread, they will never call this function simultaneously, and will sleep in serial.
I have a somewhat unusual scenario where I need to be able to outright slaughter "hung", self-hosted WorkflowInstance's after a given timeout threshold. I tried the Abort(), Terminate() and Cancel() methods but these are all too "nice". They all appear to require a response from the WorkflowInstance before they are honored.
In my scenario, a workflow entered an infinite loop and was therefore unresponsive. Calls to the normal methods mentioned above would simply hang since the workflow was completely unresponsive. I was surprised to learn the WorkflowRuntime does not appear have a mechanism for dealing with this scenario, or that Abort() and Terminate() are merely suggestions as opposed to violent directives.
I scoured google/msdn/stackoverflow/etc trying to find out what to do when Terminate() simply isn't going to get the job done and came up dry. I considered creating my own base activity and giving it a timeout value so my "root" activity can kill itself if one of its child activities hangs. This approach seems like I'd be swatting at flies with a sledge hammer...
Is there a technique I overlooked?
The only true solution is to consider this a bug, fix whatever went wrong, and consider the matter closed.
The only way to forcibly abort any code that is locked in an infinite loop is to call Abort() on the thread. Of course, this is considered bad juju, and should only be done when the state of the application can be ensured after the call.
So, you must supply the WorkflowApplication an implementation of SynchronizationContext that you write which can call Abort() on the thread that the workflow Post()s to.
I am not sure if this will work, but have you tried the WorkflowInstance.TryUnload() function? I remember this to fire off a few events inside of the workflow (been a while since I did this), so you might be able to have an event handler in your workflow that catches this and does a kill switch on itself.
Equities trading application uses a class library for getting callbacks on stock quote updates, another class library for getting callbacks on order executions or cancelations. I currently have the callbacks execute in the thread pool. I start one background thread for each callback. The threads are very short lived and the work involved includes fetching the data and notifying the observers. Once observers are notified the background thread dies. When I have strategies subscribing to over 1000 actively traded symbols I get OutOfMemory exceptions.
How can I improve this design? I was thinking of starting two threads at the start, one for quotes, the other for executions, and creating each object on its respective threads. Then just have a shared object which allows adding and removing observers to the threads. But 1) how would you keep the thread alive to receive the callbacks? 2) How can you even have a callback object which is initialized on a thread with no reference on the main thread? Is this even possible?
Any help would be appreciated.
Use a producer / consumer model with a simple queue. Then you have a set number of worker threads running and you won't have this problem.
As for how to call the callback function, you could possibly use a struct like this:
struct WorkerData
{
Data data;
Delegate someCallback;
}
when the worker is finished with the data it can invoke the callback itself.
What you've described is a general picture of your application. In order to redesign your application we concrete requirements and at least a simplified model of how the participants interact with each other. Your informal description is not precise enough to suggest a specific data structure and algorithm because without knowing all enough details we might omit something crucial and not meet your needs.
You are saying all the right words and you have a specific problem, out of memory, and you need to fix something. Go back to prototyping. Write a very small but brutally exercised program to demonstrate what you want to do. Then scale it back up to your application. It's much easier to design in the prototype size.
Edit:
Because you are running out of memory, the most likely reasons are that you have a memory leak or you simply have a near-real-time system with insufficient capacity to process the load you are experiencing. A leak might be due to the usual suspects, e.g. not detaching event handlers which you can diagnose with memory profilers, but we'll rule that out for now.
If you must keep up with quotes as they are updated, they have to go somewhere such as a queue or be dispatched to a thread, and unless you can keep up, this can grow unbounded.
The only way to solve this problem is to:
throw some quotes on the floor
get beefier hardware
process quotes more efficiently
I think you are hoping that there is a clear alternative to process quotes more efficiently with a new data structure or algorithm that could make a big difference. But even if you do make it more efficient, the problem could still come back and you may be forced to consider gracefully degrading under overload conditions rather than failing with out of memory.
But in general terms, for high performance simpler is often better and fewer threads swaps is better. For example, if the work done in update is small, making it synchronous could be a big win, even though it seems counter intuitive. You have to know what the update handler does and most of all for a near-real-time system you have to measure, measure, measure to empirically know which is fastest.
To me
I currently have the callbacks execute in the thread pool
and
Once observers are notified the background thread dies
are mildly contradictory. I suspect you might be intending to use threads from a pool, but accidentally using new 'free' (unpooled) threads each time.
You might want to look at the documentation for WeakReference.
However, I suggest you use a profiler/perfmon to find the resource leak first and foremost. Replacing the whole shebang with a queuing approach sounds reasonable, but it's pretty close to what you'd have anyway with a proper threadpool.