Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / October 2007

Tip: Looking for answers? Try searching our database.

ThreadPool.QueueUserWorkItem

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
JT - 23 Oct 2007 17:51 GMT
Hi,

I'm looking to build an application that fires off a number of processes. I
have created a class (process wrapper) that contains an instance of a Process
and some associated information like a friendly name, enum flag for status
(e.g. started, not started etc). This class will manage the state for the
process it encapsulates.

I use ThreadPool.QueueUserWorkItem to call Start on each of my process
wrapper classes which in turn calls start on the process and say creates an
instance of notepad. My question is if I hook up to some events that my
wrapper class raises during the WaitCallback does this stop the worker thread
being returned to the thread pool? Lets say after 15 mins the Wrapper process
raises one of the events I want to know about this and act accordingly.
Peter Duniho - 23 Oct 2007 19:16 GMT
> Hi,
>
[quoted text clipped - 10 lines]
> being returned to the thread pool? Lets say after 15 mins the Wrapper process
> raises one of the events I want to know about this and act accordingly.

It's not clear, since you provided no code, what the Start method passed
as the WaitCallback to QueueUserWorkItem actually does.  If it returns
immediately after starting the process, then no...it doesn't stop the
worker thread from being returned to the thread pool.

On the other hand, if the Start method doesn't return, but instead sits
and waits on the process for some reason for the purpose of raising the
events you're talking about, then yes...that would prevent the worker
thread from being returned to the thread pool, since the Start method is
continuing to execute, requiring the thread used to execute it to remain
assigned to that task.

Note that none of this really has anything to do with hooking up events.
 The act of subscribing to an event wouldn't cause this.  The real
question is only whether the method you pass to QueueUserWorkItem
returns or not.  Until it returns, the thread pool thread used to
service that work item is unavailable for doing anything else.

Pete
JT - 24 Oct 2007 09:29 GMT
Thanks Peter. I've posted some code below but from what I understand I will
return immediately and the thread will not be blocked. What does this mean
for event notification though, I assume that I will not be thread safe
because the OnProcessStateChanged handler below will be executed on a
available worker thread rather than the main thread?

public enum ProcessState { started, stopped, notstarted }
   internal delegate void OnProcessStateChangedHandler(ProcessWrapper
processWrapper, ProcessState oldState, ProcessState state);

public class ProcessWrapper
{
  public Process _process;
  public ProcessState _processState;
  public event OnProcessStateChangedHandler OnProcessStateChanged;

  public ProcessWrapper()
  {
      _processState = ProcessState.notStarted;
   }

  public void Start()
  {
      _process = Process.Start("notepad.exe");
      _process.EnableRaisingEvents = true;
      _process.Exited += new EventHandler(_process_Exited);
      _processState = ProcessState.started;

       if (OnProcessStateChanged != null)
           {
               OnProcessStateChanged(this, ProcessState.notstarted,
ProcessState.started);
           }
   }

void _process_Exited(object sender, EventArgs e)
       {
           if (OnProcessStateChanged != null)
           {
               OnProcessStateChanged(this, ProcessState.started,
ProcessState.stopped);
           }
       }
}

static void Main(string[] args)
{
ProcessWrapper process = new ProcessWrapper();
ThreadPool.QueueUserWorkItem(new WaitCallback(StartProcess),process );

process.OnProcessStateChanged += new
OnProcessStateChangedHandler(process_OnProcessStateChanged);

}

private static void StartProcess(object state)
       {
         ProcessWrapper process = state as ProcessWrapper;
         process.Start();
       }

static void process_OnProcessStateChanged(ProcessEntry entry, ProcessState
oldState, ProcessState state)
       {
         //Do something, is this thread safe?
       }

> > Hi,
> >
[quoted text clipped - 30 lines]
>
> Pete
Peter Duniho - 24 Oct 2007 19:28 GMT
> Thanks Peter. I've posted some code below but from what I understand I will
> return immediately and the thread will not be blocked. What does this mean
> for event notification though, I assume that I will not be thread safe
> because the OnProcessStateChanged handler below will be executed on a
> available worker thread rather than the main thread?

That depends on what you do in the handler.  You are right, the handler
will be executed on other than the main thread.  That means that the
question of thread safety exists, but does not tell you whether the
method is thread safe or not.

The thread can be thread safe if it does not access data used by other
threads.  It can also be thread safe if it does access data used by
other threads, but has some mechanism for ensuring synchronization of
that data.

Pete

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.