如何在DLL和Windows二进制内存之间共享静态对象 [英] How are static objects shared across DLL and Windows Binary memory
问题描述
我有一个关于DLL的设计问题，我目前正在像你所说的那样，因为维基百科指的是 DLL Hell 问题如下：
我创建了一个具有多个模块实现为DLL。这些在应用程序中使用，DLL可以加载，但并不是所有这些都是必需的。如果只有像数学这样的事情完成，它可以链接到Utilities.dll并使用它。
问题是，我有一个记录器/示踪器。这将我的所有内容记录到文件和调试控制台，调试控制台只是一个流输出。问题是如何处理多个DLL尝试使用相同的日志类。看到日志类是在这个Utilities.dll，像DataManagers.dll和其他dll之类的东西也想使用日志类功能。这包括登录到一个文件。我正在使用关键部分来确保没有发生写入冲突，但是看到关键部分在usermode中实现，我必须在某些时候切换到互斥体或类似的内核模式对象。但是在DLL内存中具有日志类的多个实例意味着我会遇到一些严重的问题，如果我只是使用一个关键部分。
我似乎不能拼凑在一起是一种方法，所有的DLL都可以使用相同的日志类实例，而不必一个一个链接到Utilities.dll。我不想将8个DLL加载到我的演示项目中，并且所有这些8都指向该日志类的一个dll，如果我需要更多的东西，如日志类，这将是一个连锁反应。有没有办法正确地做到这一点？使用类的功能，其他DLL中的DLL中的静态函数和使用相同静态函数的.exe Windows二进制文件，从而不会对写入日志文件或甚至调试控制台的输出流进行冲突。 p>
如果我完全错了，试图做不可能，请告诉我，并帮助实现尽可能接近的一些。我知道在DLL中使用Singleton模式时会发生类似的问题，但这是通过
已经尝试过的：
- 初始化DLL的类给他们一个日志库的一个实例，但是这违反了所有静态成员的类的目的。
我还发现这个问题是similair（甚至是我的全球工具的图书馆名称...），但是还没有回答我的问题有一个不同的做法，也是从'09'。 如何模拟多个实例的应用程序中的全局变量静态库的行为，但使用DLL？
您的问题根本不是DLL Hell 。
这是一个基本了解DLL如何工作的问题。每个进程最多加载一次DLL。所以，如果您的DLL被多个其他DLL使用，它仍然会在每个进程中存在一次。如果您的日志类对象在DLL中实现为单例（例如全局对象），则每个进程都有一个对象。
然后应该保护一个对象防止在此过程中同时使用。关键部分，是过程本地的，是一个完美的匹配。您不需要互斥体，因为两个进程将各自拥有自己的Utilities.DLL及其对象副本。
您可能具有如果您的记录器登录到单个固定文件，则会出现问题。在这种情况下，两个进程将尝试登录到同一个文件。这是一个设计问题，你不想破坏。保持日志输出分开，所以请确保每个记录器都写入唯一的日志文件。
I've got a bit of a design problem regarding DLL's, I'm currently in as you may call it and as wikipedia refers to it DLL Hell The problem is as follows:
I've created a system which has multiple modules implemented as DLL's. These are used in an application and the DLL's can be loaded but not all of them are needed. If only things like mathematics is done it can link to 'Utilities.dll' and use this. The problem is, I've got a logger/tracer. This logs everything to a file and a debug console for me, the debug console is just a stream output. The issue is how to deal with multiple DLL's trying to work with the same log class. Seeing as the log class is in this 'Utilities.dll' and things like 'DataManagers.dll' and other dll's want to use the log class functionality as well. This includes loging to a file. I'm currently using critical sections to make sure no write clashing occurs but seeing critical sections are implemented in usermode I'd have to switch to mutexes or alike at some point to have kernel mode objects. But this having multiple instances of the log class across DLL memory would mean I would have some serious problems if I would just use a critical section.
What I can't seem to puzzle together is a way for all the DLL's to be able to use the same log class instance without having to link to the Utilities.dll one by one. I don't want to load 8 dll's into my demo project and have all those 8 refer to that one dll with the log class, this would be a bit of a chain reaction if I would need more things like the log class. Is there a way to properly do this ? Use the functionality of a class, with static functions inside a DLL in other DLL's and in a .exe windows binary using the same 'static' functions thereby not clashing in writing to a logfile or even the output stream for the debug console.
And if I'm completely wrong and trying to do the impossible please tell me and help to achieve something as close to this as possible. I know somewhat of a similair problem occurs when using the Singleton pattern in DLL's but this is solved by
What I've tried so far:
- When initializing the DLL's classes give them an instance of the log library but this defeats the purpose of the class having all static members.
I've also found this question which is similair ( even the name of the library my global tools are in how about that.. ) but it has not answered my question and has a bit of a different approach as well as being from '09. How to mimic the "multiple instances of global variables within the application" behaviour of a static library but using a DLL?
Your problem isn't "DLL Hell" at all.
It's a matter of basic understanding how DLLs work. A DLL is loaded at most once per process. So, if your DLL is used by multiple other DLLs, it still will exist once per process. If your log class object is implemented as a singleton in your DLL (e.g. a global object), then you have one object per process.
That one object should then be protected against concurrent use within the process. Critical Sections, being process-local, are a perfect match for that. You don't need a mutex, as two processes would each have their own copy of Utilities.DLL and its objects.
You might have an issue if your logger logs to a single fixed file. In that case, two processes would attempt to log to the same file. That's a design issue that you don't want to hack around anyway. Keep your log outputs separate, so make sure each logger writes to a unique log file.
这篇关于如何在DLL和Windows二进制内存之间共享静态对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
