Win32 Fibers with openMp

[noona]

I have this application that has a serial simulator, I need to make the scheduling of its threads parallel, its threads are implemented using Win32 Fibers, so when I do the scheduling using OpenMp parallel directives I get this error "Access violation writing location" which indicates that the fibers are interfering with OpenMp threads (it happens upon calling the function SwitchToFiber( ) in an OpenMp parallel region so probably it's Fibers taking control of the context in which an OpenMp thread is exectuing) . can't Fibers be used with OpenMp or are they mutually exclusive? what other options can I try? what about TBB?

thanks

[TimP]

OpenMP will work to some extent with separately managed threads set up by the same threading library (Windows threads, in the case of Intel or Microsoft OpenMP). However, the OpenMP library is totally unaware of those threads and doesn't "schedule" them. Likewise, OpenMP doesn't currently work together with TBB, even though the latter may use Windows threads. TBB probably also wants to be in full control of all threads, but you should ask on that forum.

[jimdempseyatthecove]

Noona,

Win32 Fibers is NOT multi-threading. Fibers are effectively co-routines. If you do not know what co-routines are, think of a zipper where each side is conceptually half of a thread. SwitchToFiber is use to leap from onehalf of the thread to the other half in order to interlieve the teeth of the zipper (extend this to n-sided zipper).

Fibers are an excellent choicewhen you have a high degree of coordination between co-dependent tasks (run one tooth of the zipper on side A, then run correct tooth from side B, etc...).

However, when the teeth of the zipper can run out of sequence (more or less) andindependent of side of ziper, then multi-threading will be the better choice.

I have not experimented with using Fibers (OpenMP or TBB). So you will have to experiment.

However, it would seem a requirement (when attempting to use Fibers with OpenMP and TBB) to call once per thread the function ConvertThreadToFiber (or Ex version) and remember the LPVOID. Then create additional Fibers (withineach thread) as necessary. Prior to exiting parallel region you will have to switch back to the main fiber of that thread (and you may or may not have to dispose of the fibers too). You will need to experiment as to if each thread's fibers can persist across threading tool parallel regions (you can use TLS to facillitate this).

Jim Dempsey

[noona]

Quoting - jimdempseyatthecove

Noona,

Win32 Fibers is NOT multi-threading. Fibers are effectively co-routines. If you do not know what co-routines are, think of a zipper where each side is conceptually half of a thread. SwitchToFiber is use to leap from onehalf of the thread to the other half in order to interlieve the teeth of the zipper (extend this to n-sided zipper).

Fibers are an excellent choicewhen you have a high degree of coordination between co-dependent tasks (run one tooth of the zipper on side A, then run correct tooth from side B, etc...).

However, when the teeth of the zipper can run out of sequence (more or less) andindependent of side of ziper, then multi-threading will be the better choice.

I have not experimented with using Fibers (OpenMP or TBB). So you will have to experiment.

However, it would seem a requirement (when attempting to use Fibers with OpenMP and TBB) to call once per thread the function ConvertThreadToFiber (or Ex version) and remember the LPVOID. Then create additional Fibers (withineach thread) as necessary. Prior to exiting parallel region you will have to switch back to the main fiber of that thread (and you may or may not have to dispose of the fibers too). You will need to experiment as to if each thread's fibers can persist across threading tool parallel regions (you can use TLS to facillitate this).

Jim Dempsey

Thank you for your reply Jim, it seems running fibers in parallel is not possible, they can only be spread across multiple parallels, which is not what I intend to do with this application, so I was wondering, what can I replace fibers with especially that this is the technique the the current application uses to figure the address of the function that is to execute in a thread.

[jimdempseyatthecove]

With fibers you have explicit synchronization points at the SwitchToFiber and only one fiber within the collection of fibers spawned within the context of a thread will run at any one time. There is nothing mentioned that you cannot have multiple threads each with its own collection of fibers. This said, I would assume that in order to mix fibers with OpenMP you will have to make certain that the fiber that exits a parallel region is the fiber that entered the parallel region.

It should be relatively easy to convert fiber design back into function call design then consider multi-threading from that code base.

Jim Dempsey

[noona]

I was able to add OpenMp code in order to parallelize a loop, when I run a program that uses the parallelized application it exits prematurely somewhere in in the parallel region with the output " "The thread 'Win32 Thread' (0x1828) has exited with code 1 (0x1)"

I read somewhere that it probably has to do with the scheduling scheme, I changed it to dynamic, the program might then proceed a little further (sometimes it does and sometimes it doesn't) and then exit,when I disable OpenMp in Visual Studio 2008 the program runs correctly, could someone please point out what the problem can be?

this is the place where I add OpenMp code:

[bash]sc_curr_proc_info curr_proc_info;
sc_object* current_writer;  
#pragma omp parallel for private (curr_proc_info, current_writer, method_h) shared (exceptionOccured) schedule(dynamic, 1) 
    for (i = 0 ; i < method_process_num ; i++)
    {
         current_writer = 0;
        #pragma omp critical(dequeueMethod)  
        method_h = pop_runnable_method(curr_proc_info, current_writer);

        if(method_h !=0 && exceptionOccured == false){
            try {
            method_h->semantics();
            }
            catch( const sc_report& ex ) {
                ::std::cout << "n" << ex.what() << ::std::endl;
                m_error = true;
                exceptionOccured = true; 
            }

        }
    }




thanks[/bash]

[George_Kotorlis]

Of course it's possible to execute fibers in parallel! Furthermore, you can use user mode synchronization primitives for communication.

It's even possible to suspend a fiberby its executing thread and resume iton a different thread. The only restriction is that the fiber switch must reside outside a thread-affine code region.

Maybe you want to take a look at my fiber-based multicore framework "Fiber Pool" at http://www.thinkmeta.de/en/fiberpool_overview.html

"Multithreaded" fibers can make things possible where pure thread-based frameworks including Intel's TBB fail. On my web site you will find three examples - amulticore MP3 encoder, a multicore FLAC encoder and a multicore ZIP (de-)compressor - that show the power of fibers. It'simpossible to get a similar performance just with threads.

[justin_guo]

Dear noona,

It is a great pleasure seeing that you were using openmp to reform systemc, as systemc, one that be born to be a software running in serial, is not always considered satisfied.

I have been trying to relocate systemc on SMP recently. Firstly, I applied the API of windows to modify: creating processes as many as CPU cores with CreateThread(), setting Affinity to each process individually, and implementing modification of serial data wherever necessary. However, the result was not persuasive with performance even worse. Secondly, I analyzed the program via vtune from intel, and the result demonstrated that the context switch probability and L2 cache line miss rate were unbearably high. Thus, I doubted the optimization approach in terms of implementing CreateThread() consistently. Lastly, based on pervious efforts, I switched the program to openmp with process mainly in crunch(); as a result, the efficiency was remain negative.

I wonder whether you have made a success in rebuilding. It will be a great pleasure can share your experience and problem solving code even though I don not know whether you would like to do so. Please discuss your considerations by email if possible, my email address: excelgjc __at__ gmail.com, really appreciated