blob: 6469af90d783944db0dda4eda3c6825a2e48cea0 [file] [log] [blame]
<html xmlns:v="urn:schemas-microsoft-com:vml"
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 9">
<meta name=Originator content="Microsoft Word 9">
<link rel=File-List href="./mutex_files/filelist.xml">
<title>Mutex Documentation</title>
<!--[if gte mso 9]><xml>
<o:Author>Helena Shih</o:Author>
<o:LastAuthor>Helena Shih</o:LastAuthor>
/* Font Definitions */
panose-1:5 0 0 0 0 0 0 0 0 0;
mso-font-signature:0 268435456 0 0 -2147483648 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
/* List Definitions */
@list l0
mso-list-template-ids:-1849547252 -302606876 -817858888 -819169718 -1866726332 223118424 -996776518 -314158042 -1140712398 101464222;}
@list l0:level1
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1"/>
<body bgcolor=white lang=EN-US style='tab-interval:.5in'>
<div class=Section1>
<h1>International Components for Unicode Synchronization Issues</h1>
<p>There are a number of functions in the IBM's Classes for Unicode that need
to access or allocate global or static data. For example, there is a global
cache of Collation rules, which ensures that we do not need to load collation
data from a file each time that a new Collator object is created. The first
time a given Collator is loaded it is stored in the cache, and subsequent
accesses are extremely fast. </p>
<p>In a single-threaded environment, this is all straightforward. However, in a
multithreaded application there are synchronization issues to deal with. For
example, the collation caching mechanism needs to be protected from
simultaneous access by multiple threads; otherwise there could be problems with
the data getting out of synch or with threads performing unnecessary work. </p>
<p>We prevent these problems by using a Mutex object. A Mutex is a
&quot;mutually exclusive&quot; lock. Before accessing data which might be used
by multiple threads, functions instantiate a Mutex object, which acquires the
exclusive lock. An other thread that tries to access the data at the same time
will also instantiate a Mutex, but the call will block until the first thread
has released its lock. </p>
<p>To save space, we use one underlying mutex implementation object for the
entire application. An individual Mutex object simply acquires and releases the
lock on this this global object. Since the implemention of a mutex is highly
platform-dependent, developers who plan to use the International Classes for
Unicode in a multithreaded environment are required to create their own mutex
implementation object and register it with the system. </p>
<p>Using a single, global lock object can, of course, cause reentrancy
problems. Deadlock could occur where the Mutex aquire is attempted twice within
the same thread before it is released. For example, Win32 critical sections are
reentrant, but our testing shows that some POSIX mutex implementations are not.
POSIX would require additional code, at a performance loss. </p>
<p>To avoid these problems, the Mutex is only aquired during a pointer
assignment, where possible. In the few cases where this is not true, care is
taken to not call any other functions inside the mutex that could possibly
aquire the mutex. </p>
<p>The result of this design principle is that the mutex may be aquired more
times than necessary, however time spent inside the mutex is then minimized. </p>
<p>Developers implementing the Mutex are not required to provide reentrant-safe
implementations. </p>
<h3>Using collators in multi-threaded environment</h3>
<p>Instances of Collator class are meant to be used on per thread basis.
Although it is possible to have multiple threads access one Collator there is
no guarante that such a construct will work, especially if number of threads
grows over 10. There are no limitations on number of threads if each thread
creates its own separate instance of Collator class.</p>
<p>Test results have shown that case with 50 threads accessing 1 collator fails
with a crash after 20 threads are reached. However, a test with 50 threads
creating separate instances works well.</p>
<p>On Win32 platforms, a reentrant mutex is most naturally implemented on top
of a Critical Section.<br>
On POSIX platforms, pthread_mutex provides an implementation. </p>
<p>The International Classes for Unicode are provided with reference
implementations for Win32 and POSIX. </p>
<p><b>See also:</b> </p>
<ul type=disc>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1;tab-stops:list .5in'><b>mutex.h </b>- Mutex API</li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1;tab-stops:list .5in'><b>muteximp.h</b> - The API's
and instructions for providing your own mutexes.</li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1;tab-stops:list .5in'><b>mutex.cpp</b> - includes
reference implementations for Win32 and POSIX.</li>