I am building a profiler, and am trying to replicate the call stack of the application being profiled.
This article on profiling the CLR recommends building a 'shadow' stack using the Enter/Leave method callbacks (SetEnterLeaveFunctionHooks), rather than using the snapshot method.
Is there a way to associate these callbacks when they are part of the same call stack, but could potentially occur on different threads? (for example, when the application being profiled uses Task.Run or async/await).
Ideally, I would like to show the user a call stack that 'follows' async methods, so associating them by ThreadId is unreliable.
I'm a little new to it and I don't understand the threading term completely yet, Allthough I know how to make a thread and run programs with multiple threads. What I'm wondering about is that when you create a dll file (c++) and inject it into a process (lets say gamehacking) for instance. Would you need to create threads in the dll file, or is that not going to work? After my understanding the main thread will be running from the host process right? Or how does it work?
Well it depends on what you are planning to achieve using the DLL. If that particular DLL has some static functions / utility class, that just takes an input, doing some calculations / processing and produce an output, then there is no need of threading here.
But if that DLL is going to listen on a socket or write to a file or do the actual work that going to need some parallelism, then you might want to create threads inside that DLL.
Basically you must need to understand, what is that task, that is accomplished by this DLL. A DLL can be linked during compile time as a normal library or it can be loaded dynamically in run-time based on your need / use-case.
To answer your question,
Would you need to create threads in the dll file, or is that not going to work?
Ans : Not always. You need to create thread to accomplish some task. That being said, this is not the case always. It is perfectly feasible to run a DLL inside a process, without having any threads.
After my understanding the main thread will be running from the host process right? Or how does it work?
Ans : That's right. Any process you run, there will be one thread by default. If your application is simple enough to be processed by a single thread, then it is a blessing. Keep up with it :)
Since you are specifically refering to injecting the DLL, I have some input for you additionally to what has already been said.
First, let's make sure that the concepts of threads, processes and modules are clear.
A thread is basically the immediate environment in which code runs. Things like the current state of processor registers and stack variables (e.g. your local variables in functions, in most cases, but also where in the code the execution currently stands) belong to a thread. There are also other resources which often have thread-affinity, such as windows. It depends a lot on the resource in question whether and what kind of thread affinity they have.
Let's assume you write a simple hello world program. It will run in one thread which goes through your program from the beginning to the end and print "Hello World". Now let's assume you would want to write a program which slowly writes "Hello World", one character per second, but in the meantime download a file. Then you could create a second thread and have one thread output "Hello World" slowly, and one thread download the file. This means execution can happen in parallel, with different local state - one thread is currently inside your printHelloWorld function and one thread is inside downloadFile.
A process is basically a container for one or more threads. It bundles them together in a shared environment which uses the same virtual memory (this means that for example global variables in your code would be accessible from all threads, but this would require careful synchronization to avoid race conditions) and shares resources such as file handles the threads in the process create. So, your hello-world-and-download program from before would have 2 threads in 1 process, sharing the console for example, and being seen in the task manager as one entity.
A module is a file which contains executable code (in most cases, that is) and is loaded into a process. Usually, in a process there are one EXE file and several DLL files loaded as modules. DLL files and EXE files are technically almost the same, but EXE files are meant to be the basis from which a processes starts, and DLL files are meant to be libraries exporting certain functions which can be used by other modules. Since I said modules are loaded into processes, it means that a module is accessible by all threads in the process, and it doesn't have thread-affinity by its own - in our previous example, when the second thread downloads the file, it may be calling into a HTTP-networking DLL, whose code would then run in the second thread. There is a number of modules which is loaded automatically into each process by Windows, and others are probably loaded by certain features of your compiler.
OK, so, back to your question:
Would you need to create threads in the dll file[...]?
Per se, using a DLL has nothing to do with whether you need to create new threads or not. It depends on what you want to do - if you need to do some time-consuming task in parallel to whatever other code is running, then you would need to create a new thread for it, otherwise there is no need.
[...]or is that not going to work?
As said, you can create new threads if you want (it will work), but it's not a necessity coming with using a DLL.
After my understanding the main thread will be running from the host process right?
The main thread of the host process will of course be in the host process. (Although there is technically no "main thread", since it's perfectly valid to have the first thread in a process create a second one and then terminate, so only the second one would be running anymore, you usually do have the first thread live through the whole lifetime of the process, and you can probably call it the "main thread" in this case.) In which module the currently-running code is located, though, will depend on what the thread is currently doing.
Let me get back to the matter of "injecting": The previous answers appear to have assumed a more "normal" environment where your DLL is just linked to the program and meant to be loaded by it. In this case, your DLL's initialization routine (which is automatically run when a module is loaded into a process) would just be run in the "main thread", probably before the actual work of the process begins.
However, things are a bit different when you inject a DLL. It depends on how you do the injection:
If you inject the DLL by modifying the imports table of the host EXE, then your DLL will be loaded the "normal" way I just said. So you can expect your initialization routine to run during the process' startup, in the main thread.
If you inject the DLL by using the AppInit_DLLs registry key, it would be the same.
Same thing if you inject the DLL by starting the host process suspended, then writing a stub to load the DLL into the processes' memory and using SetThreadContext to point the instruction pointer to it.
If you inject the DLL through means of remotely calling LoadLibrary inside the target process, using CreateRemoteThread, then however, as the name suggests, you are creating a new thread inside the process. In this thread, LoadLibrary will load your DLL and also call your initialization routine, so in this case, your initialization routine would indeed run in a new thread other than the "main thread".
Every process has at least one thread. When that process starts, it's possible to link a bunch of functions, or a library, to the memory space of that process. That's what a dll is. The advantage compared to linking directly to the binary is the library only has to exist in one place in the file system and one place in memory while being used by multiple processes. It's a linking technique, similar to how .so files are used in Linux. It has nothing to do with threading.
Would you need to create threads in the dll file, or is that not going to work?
There wouldn't be any point loading a DLL that didn't contain code that would be run. That said, there are several ways the DLL code might get run:
when the DLL is loaded it gets a chance to run some initialisation code
during initialisation, it might:
start one or more threads, which can keep running - perhaps watching for some event that triggers some action on their part
register for callbacks from the OS or application, such as setting up signal handlers, keystroke handlers, any type of event handler....
it might contain functions that the program will look for dynamically and run, mistaking your DLL code for the original versions of those functions that the program came with
Which of these suits your needs depends entirely on what your DLL is trying to achieve, and what's technically necessary to achieve it. For example, if watching for some memory to have specific content, then modifying it further, it might suffice to have a function in your DLL called by an OS alarm service, resetting itself to go off again later if the triggering memory content is not found. But, the trigger might be existence of a file, or shared memory service, a socket being created etc..
After my understanding the main thread will be running from the host process right? Or how does it work?
Yes - threads started within a process - including any DLL initialisation routines - are also within the process. There are some library functions that may create other processes - such as fork, popen, system - that may contain their own threads.
I'm designing the threading architecture for my game engine, and I have reached a point where I am stumped.
The engine is partially inspired by Grimrock's engine, where they put as much as they could into LuaJIT, with some things, including low level systems, written in C++.
This seemed like a good plan, given that LuaJIT is easy to use, and I can continue to add API functions in C++ and expand it further. Faster iteration is nice, the ability to have a custom IDE attached to the game and edit the code while it runs is an interesting option, and serializing from Lua is also easy.
But I am stumped on how to go about adding threading. I know Lua has coroutines, but that is not true threading; it's basically to keep Lua from stalling as it waits for code that takes too long.
I originally had in mind to have the main thread running in Lua and calling C++ functions which are dispatched to the scheduler, but I can't find enough information on how Lua functions. I do know that when Lua calls a C++ function it runs outside of the state, so theoretically it may be possible.
I also don't know whether, if Lua makes such a call that is not supposed to return anything, it will hang on the function until it's done.
And I'm not sure whether the task scheduler runs in the main thread, or if it is simply all worker threads pulling data from a queue.
Basically meaning that, instead of everything running at once, it waits for the game state update before doing anything.
Does anyone have any ideas, or suggestions for threading?
In general, a single lua_State * is not thread safe. It's written in pure C and meant to go very fast. It's not safe to allow exceptions go through it either. There's no locks in there and no way for it to protect itself.
If you want to run multiple lua scripts simultaneously in separate threads, the most straightforward way is to use luaL_newstate() separately in each thread, initialize each of them, and load and run scripts in each of them. They can talk to the C++ safely as long as your callbacks use locks when necessary. At least, that's how I would try to do it.
There are various things you could do to speed it up, for instance, if you are loading copies of a single script in each of the threads, you could compile it to lua bytecode before you launch any of the threads, then put the buffer into shared memory, and have the scripts load the shared byte code without changing. That's most likely an unnecessary optimization though, depending on your application.
The scenario is here:
If a program is executed, at runtime assume it will link to some DLL files, the (master) program/process may or may not create multi-threading function-calls to the functions in DLLs.
Then is there a way that the DLL, of cause besides parameter-passing, can tell whether the master process, who calls the functions within the DLL at runtime, is in a single or multi-thread manner (For instance, by Open MP)?
You can check and compare the current thread ID to detect calls from different threads. You could also implement a DLLMain() function that gets called for every started and terminated thread. I'm pretty sure you can also retrieve a handle to the current process and enumerate the threads running in it. Only the first version will actually tell you if your code is run from different threads though, I think that e.g. WinSock will create a thread for you, even though your program is single-threaded otherwise.
BTW: Consider adding win32api tag and removing C++ tag.
A legacy c++ applications with sometimes notorious memory leak issues has to be called from a .Net server based windows application. .Net garbage collection times are not determinable and sometime the c++ object are destroyed or not destroyed "on time" producing unpredictable results and generally crashing the c# web app. What is the best way to push the c++ objects onto the garbage collection stack as frequently as possible, but not so often as to remove the .Net reference to the COM object. Keep in mind that the COM objects can spawn sub-objects so the .Net reference count of the COM objects can change with just a function call and not necessarily an instantiation.
As the memory leaks occur and the COM objects are not cleaned up, performance degrades until it is so slow that IIS trips on itself a few times and then crashes. Restarting IIS fixes the issue until the next time. Periodic restarts help, but a busy day can cause this during the business day.
I had to resolve this using .Net 1.1 a couple of years ago. Wondering if someone else had my solution or a better one. This is NOT ASP.NET. It is a .Net dll.
The final result was not completely satisfactory and the web server crashes every few months.
You ask "What is the best way to push the c++ objects onto the garbage collection stack as frequently as possible", but c++ objects are never garbage-collected. Maybe look at it this way...
You have a process that instantiates a bunch of c++ objects. Some of those c++ objects implement COM objects, and their lifetime is therefore managed via AddRef/Release. Some of those COM objects are imported into the .NET world, and are wrapped with an RCW (runtime-callable wrapper). Only the RCW is a .NET object and goes in the garbage-collected heap.
Without any intervention from you, the RCW will eventually be GC'd and when that happens it will do a Release against its underlying COM object. If you want to Release the COM object immediately, without waiting for GC, you can call...
System.Runtime.InteropServices.Marshal.ReleaseComObject
... or even FinalReleaseComObject if you're sure it's what you want.
To get back to your question: you want to know how to delete the c++ objects without releasing the .NET reference to your COM object. Since the c++ objects don't exist in the .NET heap, there's no way to achieve this directly. You could expose a method from your COM object that deletes all its c++ objects, and simply call that from your .NET code. But I guess if it was possible for your COM object to identify all the leaked c++ objects you'd be doing that already.
Hopefully I've explained why there's no way to achieve what you suggest in your question, but there are plenty of tools around to help you find and fix your memory leaks. I suggest using a tool such as LeakDiag (search StackOverflow for it) to find out where your c++ code is leaking memory.
The pragmatic solution, if you're using IIS6 or higher, is to configure application pool recycling. You can tweak the numbers so that processes are killed and restarted before they've ever leaked enough memory to be problematic, and it normally works in such a way that users don't notice any downtime.
Create a COM+ application and put the COM classes you use inside that application. This way all COM objects are instantiated in a separate process. You can periodically release all COM objects and just restart the COM+ application process.