Archived

This topic is now archived and is closed to further replies.

singleton in a DLL - repost in right forum section

This topic is 5571 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a class I want to use as a singleton class, however i''m trying to work out something. If the class only has one instance in a program, is that only one instance in the DLL and any process the dll is attached to, or does each process get its own copy of the class in its own address space? (repost coz i put it in the wrong place last time)

Share this post


Link to post
Share on other sites
Win32 - and most 32-bit os''s that have virtual memory managers.

Each process is given it''s OWN address space

So each process would have it''s OWN copy of the singleton.

You''d have to do some sort of interprocess memory sharing ( aka file mapping ) in order to share one copy across multiple-processes.

Share this post


Link to post
Share on other sites
The DLL runs in the address space of the attached process, so there''ll be a different one for each process attached. If you need to have one for all attached processes, there''s ways around it (like putting the singleton in a shared section) but it might be a better idea to use other methods...

If I had my way, I''d have all of you shot!


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
fair nuff, I'll just have to stick to my current solution of using a shared memory section in the DLL to share varibles and using another DLL with a system to call functions in the other processes address space for function calls.

cheers for the replies

[edited by - _the_phantom_ on September 10, 2002 6:02:04 PM]

Share this post


Link to post
Share on other sites
quote:
If you wish to share the same instance across various threads and processes then check out the volatile keyword.


You cannot share the same instance across processes because they cannot access each other''s address spaces. I suppose that you could change the permissions with the virtual memory functions, but there are generally better ways of doing InterProcess Communication (IPC).

The volatile keyword does not help the original poster with his problem, but yes, volatile can be useful in multithreaded programming.


quote:
so, i should probably prefix all my varibles in the DLL shared memory space with that to stop things going odd on me then?


The proper use of volatile is very specific and not too often encountered in multithreaded applications. Here is how it works. Compilers often take your code and in the process of optimization they change it into machine code with slight semantic differences. In ordinary code this is rarely a problem.

However, certain multithreaded code relies on some code snippets involving that variable translating into *exactly* the right machine code. The volatile keyword just prevents the compiler from doing anything tricky. If you use volatile unnecessarily, you could prevent some nice optimizations.

IIRC, the Linux kernel uses volatile to good effect.

Share this post


Link to post
Share on other sites
well, I''m not sure that the code around it is REALLY timing critical (its a Windows GUI app so a few extra clock cycles aint gonna kill the fps), that said I havent had any problems with values not being what I expect ''em to be, so I''ll leave it off and keep it in mind for now

Share this post


Link to post
Share on other sites