Mutex Problem

[P1]

I have a piece of code I am limiting to a single instance on a W2K3 server with multi-processors and multiple terminal sessions ( With Remote Desktop ).

The mutex does not work across the multiple terminal sessions.  So in effect, I can create the same mutex in all terminal sessions including the current deskstop window.  So I am getting multiple instances of the same code running.

I have been doing research on MSDN with no results as of yet.

Has anyone ran into this problem before?

Does anyone have a single instance code technique that does work for a server with multi-processors and multiple terminal sessions?

Regards,  P1  :8)

[Tedd]

Synchronize on a file?

Open the file with an exclusive lock, run the code, and then release it when you've finished. Anyone else trying to open the file will fail and can't (shouldn't) run the code. The file itself would be on the server, and zero length.

[P1]

Exclusive File Locking solved one problem, But ....

I have a new problem.   :tdown

I can not distinguish which VM session is going to get "there" first.  This piece of software should only run in the physical server console desktop and not in a remote desktop session.

Any ideas ?  I will run it as a service, if I have too.

More research.   :eek

Regards,  P1  :8)

[Tedd]

Shouldn't the server program be different from the others?
And if only the server vm should be running the code, then why should the others even attempt to?
Unless it should be the server first, and then any others?
I suppose you would want some kind of identifier for each session and limit based on that.

[P1]

I have MacroScheduler Running on the server for timing of automated tasks.  If I ( or another Admin ) remote desktop into the server, the remote session is running a copy of MacroScheduler too.  So the same task gets started twice.  But the seperate VM sessions are not aware of the each other.

It's boiling down to managing the VM sessions and/or a re-write to a service.

Regards,  P1  :8)

[Tedd]

All I can think is that each VM should check where it is actually running and then only run if it's really on the server.
If the server has a file containing its hostname, then each session could check its own hostname against the contents of that file. But this assumes getting your 'own' hostname will return the local hostname and not the one of the remote session.

[P1]

All I can think is that each VM should check where it is actually running and then only run if it's really on the server.

That's today research project, to find some code to ID the VM sessions.

Thanks for your input so far !!!

Regards,  P1  :8)

[P1]

Here is the code snippet to limit code to either Console Only Mode or Execute for a Remote session.
Note:  For Windows Terminal Servers, W2K and Up.

Code Select Expand

invoke GetCurrentProcessId
invoke ProcessIdToSessionId,eax,addr dwSessionID
mov eax,dwSessionID
or eax,eax
jz Console
;invoke MessageBox,0,ADDR szRemote,ADDR szMsgTitle,MB_OK
jmp The_Exit
Console:
;invoke MessageBox,0,ADDR szConsole,ADDR szMsgTitle,MB_OK


Regards,  P1  :8)

[lingo]

some ideas here:
http://www.developerfusion.co.uk/show/1716/8/

Regards,
Liingo

[P1]

He points out that in the Terminal Server edition of NT (which is built into Windows 2000), the kernel no longer has a single "global" namespace, but in fact each Terminal Server session has a private namespace. System services share a common namespace for what is called the "console session". He points out that "this all results in consuming much more memory and making some programming tasks quite tricky, but the result is that every user logged into the Terminal Server is able to start its E-Mail client".

Thanks for making my point.

So this is why I/you need the code above.

Regards,  P1  :8)

[sluggy]

Here is the code snippet to limit code to either Console Only Mode or Execute for a Remote session.
Note:  For Windows Terminal Servers, W2K and Up.

Excellent :) I've had to code for terminal sessions before, but never to restrict the app to only one instance. Personally i was thinking you needed a service, but kinowing an alternate option is great  :U

[P1]

... Personally i was thinking you needed a service, but kinowing an alternate option is great  :U

Well, this is a special case these days.  Most rack servers don't have a physical console.  But we maintain a a rack with a KVM to all servers.  I have found, in a pinch, you need to be at the server with a phyiscal connection.  When they get a RDP that works with a BIOS setup screen, we can drop it then.

I deal with the physical and spiritual issues of computing.

Regards,  P1  :8)