Threads and cross-process (maybe?) signals

[zachattack05]

If I start a new thread, and that thread executes a method that is contained in a referenced dll, how do they signal each other? Would this be considered a cross-process EventWaitHandle? It doesn't seem like it would be considering that the thread is started in the same process. I always pictured a "cross-process" as two separate executables that signal each other, but maybe it applies to references as well? I can't seem to figure this one out. Any suggestions would be great!

[Momerath]

I'm not sure what you are asking. There is no signaling done when a thread executes something in a referenced DLL (unless the code being executed explicitly does thread signaling, just like any other code).

[zachattack05]

No no no...let me clarify.

Say thread1 starts running and something happens and it needs to spawn off a new thread, but after it spawns it off it calls WaitOne() and waits for the thread it started to call Set()

For example...

CountdownEvent ThreadSignaler = new CountdownEvent(1);

        private void InspectEnvironment()
        {
            Action SignalDone;

            //initialize a thread to check for sql servers
            Thread FindSqlServersThread = new Thread(FindSqlServers);
            FindSqlServersThread.Name = "Find SQL Servers Thread";

            //start the threads
            FindSqlServersThread.Start();
            ThreadSignaler.Wait();     //wait for the FindSqlServersThread to finish.

            //continue working...
        }

        #region Threaded

        private void FindSqlServers()
        {
            //Simulate some boring task
            Thread.Sleep(3000);

            //The thread is tired of living, and commits suicide
            ThreadSignaler.Signal(1);
        }

This code works wonderfully! But they are both in the same class, and same namespace.

Assume for a moment that "FindSqlServers()" is NOT located in the same class or namespace, but is actually located in an external dll file that is only referenced. I can't call ThreadSignaler.Signal(1); in the dll because ThreadSignaler doesn't exist in the dll, and if I create it, wouldn't it be a different instance of the wait handle? It seems like it would be signaling the wrong one unless I use a cross-process signal?

[Momerath]

This is one of the issues you'll encounter when you try to make thread safe code :)

If the main code requires the Wait() call you'll have to wrap the call to the DLL in code that makes the Signal call.

The method in the DLL has predefined behavior. If you wish to add behavior to the call (in this case the Signal call) then you'll have to 'decorate' the call with the additional behavior. This is known as the Decorator pattern. It generally applies to objects, but in this case you just want to decorate a method.

[zachattack05]

I have the dll source. It's a project in my solution. Would this still be a preferred way? I can modify the dll, it's not a third party file :)

Remember the server I was working on...remember I was going to have a "server core?" That server core is the dll I'm talking about. I have a button on my management form that allows the user to start the server. I would like that button click to create a new thread and run the "StartServer()" method on the dll. But I want to make sure that the server has completed starting before moving on.

[Momerath]

Personally I'd have the StartServer method spawn the thread, rather than some other code. This way the method returns only when the thread starts, keeping that logic ecapsulated from your management form. StartServer could return a boolean indicating success.

[zachattack05]

Ooooh I like it!
Excellent idea! Thanks!

But still, my curiosity has the best of me...would that be a cross-process signal or did I miss something?

[Momerath]

Yes, it would be a cross-process signal

[zachattack05]

Thought so.

Thanks!