none
Number of sub-threads are increasing when OpenMP is used in a spawned Win32 thread... RRS feed

  • Question

  • OpenMP support in VS2005 is very nice feature, and our team is now using it intensively.
    However, we've found a very big problem in OpenMP that the number of threads are increasing.

    When using OpenMP in VS2005, the created sub-threads still remains even if the parallel-construct finished. In usual cases, it would not be so problematic since the reamaining sub-threads are re-used when another OpenMP parallel construct enters into action.

    However, when we use the OpenMP funcion in a spawnd Win32 thread, the remaining sub-threads are not re-used.

    Here is an example to reproduce it:

    static WorkerThread( LPVOID )
    {
        ::omp_set_num_threads( 4 );
        #pragma omp parallel
        {
            TRACE( _T("Thread Id: %d\n"), ::GetCurrentThreadId() );
            // do something
        }
        return 0;
    }

    void CDlg::ButtonEventHandler(void)
    {
        ::AfxBeginThread( WorkerThread, NULL );
    }

    I checked the number of threads in the Windows Task-Manager and the VS2005's debugger.
    Using the above code, you can see the number of threads in the process is increasing whenever the 'ButtonEventHandler()' is called.

    If we call directly WorkerThread() instead of creating a Win32 thread, then the number of threads is increased only at the first time.

     

    Monday, December 18, 2006 8:53 AM

All replies

  • Dear Jaeyoun Yi,

     

    we discovered the same problem in our software.

    Do you have a solution for it in the meantime?

     

    Your help is appreciated.

     

    Monday, July 9, 2007 9:12 AM
  • It looks like the issue is that when we spawn a Win32 thread, that thread is not part of a thread team, so we create a new parallel region with new threads. 

     

    In the other case, you are already part of a thread team, so unless you have OpenMP nested parallelism enabled, you won't get new parallel region created if the particular thread is already in a parallel region.  To turn on nested parallelism do omp_set_nested(1) and see if that gives the same thread-growth behavior for both versions of the code.

     

    At least, that's what it looks like.  Let me know if I made an incorrect assumption.

     

    Thanks,

    Wednesday, July 11, 2007 8:26 PM
    Moderator
  • And what happens if you start the thread with _beginthreadex?

    Thursday, July 12, 2007 6:15 AM
  •  

    In my opinion, this problem is not related to nesting stuff. In Open-MP in VS2005, it seems that thread-teams are pooled in a sort of thread-pools, to reduce some overhead in creating/destroying sub-threads. And we've found that this thread pool is created per each master-thread (who spawns a parallel construct) and it will be kept alive till the process ends.

    Therefore, in the example I showed in the first message, number of sub-threads increases whenever a newly created thread runs an open-mp constructs.

     

    To resolve this, we had to make an our own thread-pool of 20 running threads. By this, we could confind the number of sub-threads to multiples of 20 (Our pool size).

     

     

     

    Monday, July 16, 2007 8:47 AM
  • If that solves your problem, then you're good   :-)

     

    But I'd try enabling nested parallelism for kicks to see if that duplicates the thread growth (regardless of the threadpool that you create).  I suspect it will.

     

    Thanks,

    Wednesday, July 18, 2007 12:35 AM
    Moderator
  • Is this issue been resolved?

    the thread number still keep increasing if use OpenMP.

    Friday, March 25, 2011 9:50 AM