We are developing and enterprise application with plugin-based architecture. Every plugin implements a contract that has a bunch of methods. All of those plugins are used in runtime by our core system and have their methods called permanantly. All of those calls must be async and in no way blocking.
We also give the ability for 3rd party developers to develop thier plugins. The problem is that this developers might implement some methods, which will not be async (by mistake or not). The worst case scenario is that this method will contain infinite loop.
We can put the call into separate thread, but after a couple of calls, those loops will take all the CPU time and could hung the system entirely.
Is there a way to ensure that those calls are not blocking and not resource critical?
P.S. We can drop any plugin at runtime if it's suspicious.
Related
I have created a Matlab dll that includes two functions. Function1 takes 3-4 millisecond to run and Function2 takes around 1 second. I need to run Function1 in C# continuously and Function2 time to time. I experienced that when I run Function2, Function1 does not run continuously or it takes a lot more than 3-4 millisecond (something in the range of 2-3 second). Function1 returns to normal/fast state as soon as Function2 is completed. These are what I already tried:
I called Function2 in a separate Thread, with no luck! (Function1 is also running in a separate Thread).
I used backgroundworker instead of Thread (just in case), with no luck!
I created a separate dll just for Function2, and again I experienced same issue/delay/latency.
Does anyone have any idea/solution for this problem? Does Matlab run functions/code in single thread? If not, is there anyway to specify separate thread for Functions?
I appreciate any help.
It seems like your intuition is correct: Calls to Matlab libraries are executed sequentially, even if originating from multiple threads. Refer to the comments by Peter Webb under Creating C++ Shared Libraries and DLLs:
You can call the libraries from multiple threads, but only one thread can be active in a library at any time. The generated libraries are protected by semaphores, which only allow one user thread into the generated library at any one time. Other user threads that try to call into the shared library will block (wait) until the shared library is “free”.
[...]
The libraries protect themselves with semaphores. They do so because the underlying execution engine (the MCR) is not thread safe. This means that even if you could disable the semaphores, you wouldn’t want to, since you’d likely get incorrect results or program failures.
If you truly need parallelism, currently your best (and only) option is to use separate processes. If your client can speak any of the standard web protocols (HTTP or JSON) or Microsoft’s proprietry extended versions, it’s pretty simple to set up web-based WCF clients in separate processes using WCF. (Of course, your servers have to run on Windows machines in that case.) See my WCF post for details.
I often find when I'm writing a service class (within an ASP.NET app) that in addition to the usual method calls, I'd like scheduled method calls which invoke, say, every day at 1am.
My idea is to create a custom attribute which would be used against any scheduled task methods:
[ScheduledTask(Every=TimeSpans.Day, At=6)]
public static void Cleanup()
{
// some clean up code here
}
In order to implement this, I would have to scan the assemblies loaded in the AppDomain at the web app's Application_Start method. Look for static methods with the ScheduledTask attribute and then invoke the scheduler to run these methods according to the attribute.
I've looked around the net and found that no-one else seems to have done this and wondered whether this is generally a bad idea for some reason!? Would it be possible do you think?
thanks!
Some problems I see:
Separation of concerns. Your class provides the Cleanup implementation and the schedule to run it. An administrator is likely to want to control the schedule (e.g. run Cleanup at times of low activity), so it's more common to use configuration to provide a schedule.
Difficult for an administrator to get an overview of what tasks are scheduled.
Interpretation of the schedule. Is your example 6 UTC or local time?
Ease of modification of the schedule - you need to recompile.
ASP.NET applications can shut down, e.g. after a period of inactivity, or on a predefined schedule, and won't start up again until another request arrives. Which makes IIS a poor host for running scheduled tasks.
I had an idea for solving the problem of enumerating managed threads in .Net and for tracking thread ancestry (which thread created which other thread).
If it were possible to tag a Thread object with an object of the programmer's making that is automatically copied to children threads when they are created, it might be possible to use that tag to track when new threads are created, who created them, etc. The inspiration came from unix, where, when a process is forked, it inherits open file handles, etc. If there were some piece of data that is 1) thread-local or tied to a Thread object and 2) is automatically copied to new threads and 3) is modifiable, that would be a good start.
I'm guessing that we'll have to use reflection to access members of some of the Thread object that starts the chain because most of what i see in the thread that might be useful is otherwise locked up, but it's an start. I'm not sure how wise this approach is though.
Edit:
I think I'll explain my use case better because I don't think anybody understands.
I know about tracking threads explicitly, which I've done widely in code i own before. That's not the problem.
Basically, I'm trying to implement a 'thread-group-context', much in the same way that .Net has an appdomain-context, a remoting context [1] and an assembly-thread combination-local context [2].
For a given group of threads that were spawned from a common thread, I want to associate information with that grouping. While I understand that .Net doesn't have this concept (else I would have no problem!), it doesn't change the fact that every managed thread in .Net was created by one and only one other managed thread, and thus, can be drawn in a tree structure.
The problem I am trying to solve is thus: I have an API, that has an context object. This API calls into a large external library of code that does real work, and does so starting from a thread of its creation. That external does not explicitly get a copy of the API context object, however it would need one in order to make calls on the API. Since it does not have a reference to the API context object, it cannot make these calls. As things stand today, the external library does need to make calls, and to do so it looks up the current context object in a single static field, meaning that there can only be one instance of my API per AppDomain. I wish to fix this.
This external library is partly out of my control, and the interface between my API and the external library does not explicitly pass the context object. Up until now, when the external library needed to make calls into the API, it would look at a static field in my API to get a reference to the context object.
The problem is then that a final executable can only have one instance of my API session per AppDomain, because we're using static fields to pass the context object to the external library (workhorse) code.
One option is to make a GetContextObject() method in my API. When the API spawns the thread to run the external library code, it would remember that thread in a shared static dictionary. When the external library code calls GetContextObject(), it would look up what thread it is running on and return the proper context object for that thread.
If the external library code never created its own threads, then I'd have no problem, I'd always have a 100% correct mapping of thread to context. However, the external library does make its own threads, and does so without my API being aware. When the API receives a call from those threads, it won't know what context object to give up, and has to guess - if there's only one context object registered, it uses that, otherwise, it throws an exception saying it can't tell you.
If I could have data tagged to thread objects that is inherited by threads created by that parent thread, then I could implement this tracking system.
Also, the external library does not use the thread pool.
Basically, my options are thus:
1) Redesign the interface between my API and the external library to pass in the context object, and redesign the external library to correctly pass around this context object. Involves trundling through ~1 million LOC.
1a) Forbid the external library from directly using the Thread object, and instead require them to use my own MyApiThread object that, when created, adds itself to my custom tracking mechanism. Requires changing less code in the external library than option #1, but still involves a lot of rework.
2) Force the consumer of my API to start each API session in a new AppDomain so that I can store my context object in a static field (this is the 'solution' today). AppDomains involve a lot of overhead and I do not wish to force this upon my users.
3) Find a way to track thread ancestry to be able to return the correct context object to the code calling from the external library based on the calling thread. This is the subject of this post.
To those saying that Windows does not have a concept of child-parent threading, you are off base - that is irrelevant. DotNet is not a Windows-only system, and its very design was to isolate it from the machine and OS it is running on, which is why .Net exists for Linux, Solaris, FreeBSD in the form of Mono. Furthermore, Java does have the very concept of thread ancestry that I need, and Java is implemented on Windows, thus this is a very possible and reasonable concept. While I realize that the .Net api has a certain Microsoft-specific bend to it, realize that, largely, .Net and Windows are independent.
In fact, I'll make my comment an answer and point you at Jeffrey Richter.
The CallContext class gives you the ability to store data for a "logical execution path", which can cross threads and AppDomains.
Just adding more info for shambulator answer.
CallContext.GetLogicalData and CallContext.SetLogicalData do the trick
I have an unmanaged C++ DLL that my .NET application uses via p/invoke. The method that I need from this DLL is fairly time consuming and I would like to parallelize the method calls. The problem is that it uses a bunch of statics and globals, so it is not thread-safe (and can't be changed). My plan was to overcome this non-thread-safe issue by calling the unmanaged DLL from multiple AppDomains in parallel.
I can call the unmanaged code from the multiple AppDomains without any problems as long as I don't do it in parallel, but as soon as I make the calls in parallel, I get an AccessViolationException. I am using Parallel.For() to make the parallel calls.
Is it possible to make a non-thread-safe unmanaged DLL "thread-safe" by simply making the calls from multiple AppDomains?
Calling the native method from multiple AppDomain instances won't help you at all here. AppDomain boundaries don't apply to native DLL's and they won't provide any benefit
First and foremost: Load multiple copies of dll in same process
You'd have to make sure that all invocations within an AppDomain are on a single thread.
ParallelFor cannot make that happen, so you'd need to
manually parallelize (chunk up your loop for each thread/appdomain)
better (IMHO): write a wrapper function that will use a specific instance of your native dll (e.g. by using a reference to the AppDomain from threadlocal storage?).
Note that depending on the complexity of your situation (callbacks, use of global data in managed library) you might want to limit execution of each AppDomain to a specific CPU core (core affinity: see Begin/EndThreadAffinity). I might be a tad paranoid here :)
Wrap the C++ DLL in an EXE and parallelize process invocations (instead of running this code in threads or AppDomains). I had this problem with GeckoFX, which doesn't like threads, and this solution worked just fine. Of course, it's up to you to manage communication with these processes. I blogged about this some time ago.
is it acceptable to use ThreadPool in a library?
because that obviously might cause some unpleasant problems if the user of your library is using ThreadPool as well (due to ThreadPool being a static class of course)..
what's the convention?
Yes.I think it is appropriate to make use of the ThreadPool in library code. Even if the user may use ThreadPool outside, ThreadPool is still good enough to tune itself.
On the other hand, as a library developer, you should provide flexibility: user may choose to use ThreadPool, a specific thread(s), or even a 3rd party thread pool implementation.
Yes.
As long as it's well documented, and you provide methods to allow the user of the library to control the threadpool, such as min/max threads and maybe the option to not use a threadpool at all.
You should also make it very clear which exposed parts of your library are threadsafe and which are not.
ThreadPool is designed to be used by multiple components simultaneously. So it in itself presents no particular problem if used from your particular library.
What can be a problem is threading behavior in general in your library. It must be clearly documented what the threading semantics of your library are. How these threads are created and used should should be an implementation detail. The ThreadPool itself shouldn't present a problem unless one of it's inherent properties (COM apartment affinity, inability to cancel threads, etc ...) presents a problem for your API or consumers.