"Fossies" - the Fresh Open Source Software Archive

Member "mapm_4.9.5a/MULTI_THREAD/README" (21 Feb 2010, 3963 Bytes) of package /linux/misc/old/mapm-4.9.5a.tar.gz:

    1 
    2 Information from  
    3 
    4 Martin Pfingstl (Martin.Pfingstl@epost.de)
    5  
    6 on using the multi-threaded capable functions of MAPM
    7 under MS Windows (using Microsoft Visual C++)
    8 
    9 The default MAPM library is *NOT* thread safe. Martin
   10 created a set of stand-alone function wrappers so
   11 the MAPM library is thread-safe when using these 
   12 function wrappers.
   13 
   14 The general idea is to create a 'semaphore' from the
   15 operating system which guarantees that only 1 thread
   16 will have access to a critical section of code. The 
   17 following 4 functions will need to be created which 
   18 will depend on the compiler you are using.
   19 
   20 void	m_apm_enter(void)
   21 void	m_apm_leave(void)
   22 void	m_apm_init_semaphore(void)
   23 void	m_apm_free_semaphore(void)
   24 
   25 
   26 The example in mapm_mt.c shows how it is done
   27 with the latest Microsoft compilers. Other compilers
   28 should have similiar functions if they support 
   29 multi-threaded applications.
   30 
   31 The general usage is as follows:
   32 
   33 1)  compile the library normally, with make, script, batch file, whatever.
   34 2)  compile mapm_mt.c to create mapm_mt.o[bj]
   35 3)  all MAPM functions which are thread safe will have '_mt' at the end.
   36     i.e., m_apm_sqrt becomes m_apm_sqrt_mt. all user defined functions 
   37     have a thread-safe equivalent which has '_mt' on the end.
   38 4)  in the C++ wrapper class, the MAPM datatype becomes MAPMMT.
   39 5)  compile your application using m_apm_mt.h instead of m_apm.h
   40 6)  link your app with mapm_mt.o[bj] *and* the original library.
   41 
   42 M. Ring   June, 2002
   43 
   44 ----->
   45 
   46 From Martin:
   47 
   48 In order to make code multi threading capable, one has two possibilities:
   49 Either one writes functions using no global parameters, or - second
   50 possibility - one makes the functions so that only one thread can execute
   51 them simultaneously.
   52 
   53 I implemented the second possibility and it works very good.
   54 
   55 The basic idea is:
   56 1. create a semaphore (mutual exclusive object, operating system ensures
   57 that only one thread can "have" it). Operating sytem provides functions for
   58 obtaining and releasing it. Once a thread has ownership of the semaphore,
   59 any other thread who wants ownership simply must wait (i.e. the ownership
   60 call blocks the thread and returns as soon as the other thread has released
   61 its ownership).
   62 
   63 2. For each publically available function in your library I created a second
   64 one with the same name but adding the extension "_mt" (multi threaded),
   65 which does the following:
   66 
   67 m_apm_xxx_mt(x,y,z);
   68 {
   69   obtain semaphore();
   70   m_apm_xxx(x,y,z);
   71   release semaphore();
   72 }
   73 
   74 In addition to that I created a C++ wrapper class MAPMMT, which does exactly
   75 the same as MAPM except it calls the new "_mt" functions to provide thread
   76 security.
   77 
   78 For example, use function 'm_apm_sqrt_mt' instead of 'm_apm_sqrt'.
   79 
   80 In order to use it you need to include m_apm_mt.h in your application.
   81 
   82 The file mapm_mt.c is a stand-alone module now and it should be linked
   83 in with your application. The compiled object file could also be added 
   84 to the library if the user desires.
   85 
   86 The beginning of file mapm_mt.c contains platform specific stuff (semaphore
   87 handling): Currently only code for MS Windows is available. Their meaning
   88 should be self explanatory. Code for other operating systems must be added.
   89 
   90 Before using any "_mt"-function the user now has to initialize the semaphore
   91 by calling m_apm_init_semaphore.
   92 
   93 After that the user of the library can decide whether to use the old
   94 functions or the secured functions, depending on the needs. The user can
   95 also call m_apm_enter(); to manually get ownership of the semaphore, call all
   96 the old functions (your original functions) and at the end call
   97 m_apm_leave(). So the overhead from constantly getting and releasing
   98 a semaphore tends to go near 0.
   99 
  100 I tested the speed of m_apm_enter() and m_apm_leave on my system: The
  101 result was that it can do about 30 000 000 m_apm_enter and m_apm_leave's
  102 per second (2 Ghz Athlon).
  103 
  104 That's about the speed of 3 floating point divisions, or in other words:
  105 overhead from that functions is near 0.
  106 
  107 Martin
  108