Need Input from Threading Guru

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Phillip N Rounds

    Need Input from Threading Guru

    I'm cursed by being a linear thinker.

    Anyway, I have an application (service) where I can't decide on the
    appropriate way to implement threading.

    I have a timer which periodically initiates Process A
    Process A does something, then has to call N instances of Process B, where N
    varies from instance to instance of Process A.
    Process B then has to call M(n) instances of Process C, for each n < N,
    where again the # of instances of Process C varies for each call to process
    B.

    Clearly, I can do the following: ( process A & B are really in seperate
    worker classes, but this is a simplified version)

    Main Class

    OnTimer( )
    {
    int N = CalculateNumber OfProcessARequi rements();
    for ( int i = 0; i < N; i++) {
    Thread t = new Thread( new ThreadStart( this.ProcessA);
    t.Start(); }
    return;
    }

    ProcessA()
    {
    int M = CalculateNumber OfProcessBRequi rements();
    for ( int i = 0; i < M; i++) {
    Thread t = new Thread( new ThreadStart( This.ProcessB) }
    return;
    }

    ProcessB()
    {
    DoTheActualWork ();
    return;
    }

    My question is, how do I do the book-keeping.



  • Marcos Stefanakopolus

    #2
    Re: Need Input from Threading Guru

    My, that's a lot of threads...

    Regardless, it's pretty unclear what you mean by "do the bookkeeping".
    Assuming you mean "how do I keep track of the data coming back from all
    those DoTheActualWork () calls, my inclination would be to:
    1. create an event in the Process B class which the class can raise to
    indicate that a DoTheActualWork () call has finished, and has some results to
    share. Create an EventArgs-derived class to hold the actual results you
    want to pass back to the rest of the program.
    2. Have an event handler in the main part of the program to process all the
    events arising from those DoTheActualWork () calls.

    If you need to keep track of which particular instance of DoTheActualWork ()
    was responsible for a given result, then make sure to give all your threads
    unique names when your ProcessA() routine creates them. The individual
    this.ProcessB() calls can get their own thread name and include that as part
    of their results when they pass results back to the rest of the program via
    the EventArgs class. If you're clever about how you name your threads,
    you'll be able to determine which thread was which when the results come
    back.

    If you mean something else by "do the bookkeeping", you'll just have to be
    more specific...

    "Phillip N Rounds" <prounds@cassan dragroup.com> wrote in message
    news:uJQ1eDIEFH A.3888@TK2MSFTN GP09.phx.gbl...[color=blue]
    > I'm cursed by being a linear thinker.
    >
    > Anyway, I have an application (service) where I can't decide on the
    > appropriate way to implement threading.
    >
    > I have a timer which periodically initiates Process A
    > Process A does something, then has to call N instances of Process B, where
    > N varies from instance to instance of Process A.
    > Process B then has to call M(n) instances of Process C, for each n < N,
    > where again the # of instances of Process C varies for each call to
    > process B.
    >
    > Clearly, I can do the following: ( process A & B are really in seperate
    > worker classes, but this is a simplified version)
    >
    > Main Class
    >
    > OnTimer( )
    > {
    > int N = CalculateNumber OfProcessARequi rements();
    > for ( int i = 0; i < N; i++) {
    > Thread t = new Thread( new ThreadStart( this.ProcessA);
    > t.Start(); }
    > return;
    > }
    >
    > ProcessA()
    > {
    > int M = CalculateNumber OfProcessBRequi rements();
    > for ( int i = 0; i < M; i++) {
    > Thread t = new Thread( new ThreadStart( This.ProcessB) }
    > return;
    > }
    >
    > ProcessB()
    > {
    > DoTheActualWork ();
    > return;
    > }
    >
    > My question is, how do I do the book-keeping.
    >
    >
    >[/color]


    Comment

    • Jon Skeet [C# MVP]

      #3
      Re: Need Input from Threading Guru

      Phillip N Rounds <prounds@cassan dragroup.com> wrote:[color=blue]
      > I'm cursed by being a linear thinker.
      >
      > Anyway, I have an application (service) where I can't decide on the
      > appropriate way to implement threading.[/color]

      I think the best way of thinking about how many threads to have is to
      think about how many of your processes could *actually* do work in
      parallel (rather than just waiting for access to the CPU, for
      instance). I'd then think about using a custom thread pool to create
      that many threads (possibly one thread pool per process type) and give
      the thread pool jobs from the results of the processes.

      I have a custom thread pool you could use here:
      Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.


      and an article about threading which you might find helpful here:
      Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.


      --
      Jon Skeet - <skeet@pobox.co m>
      Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.

      If replying to the group, please do not mail me too

      Comment

      • Cor Ligthert

        #4
        Re: Need Input from Threading Guru

        Phillip,

        In additon to the others, think about using queue's.

        That will as well need threads however probably you can than do better
        book-keeping.

        Just my thought,

        Cor


        Comment

        • Phillip Rounds

          #5
          Re: Need Input from Threading Guru


          Sorry all, but I hadn't intended to send this question yet.
          As most of you noted, I had to further explain the 'Do the bookeeping'
          aspect of the question.
          I decided to step back before I posted, based on the possiblity that if
          I were to fully explain that portion of the post I might actually come
          up with a solution myself.
          Thanks for the input and, again, sorry for the poorly worded post.

          Phil

          *** Sent via Developersdex http://www.developersdex.com ***
          Don't just participate in USENET...get rewarded for it!

          Comment

          Working...