Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

mention that Win32 mutexes are always recursive

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@49015 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin
2007-10-02 11:31:02 +00:00
parent e74f12021d
commit 8de93aba53
1 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
docs/latex/wx/mutex.tex
View File

@@ -8,10 +8,11 @@ resource as only one thread at a time can own a mutex object.
Mutexes may be recursive in the sense that a thread can lock a mutex which it Mutexes may be recursive in the sense that a thread can lock a mutex which it
had already locked before (instead of dead locking the entire process in this had already locked before (instead of dead locking the entire process in this
situation by starting to wait on a mutex which will never be released while the situation by starting to wait on a mutex which will never be released while the
thread is waiting) but using them is not recommended and they are {\bf not} thread is waiting) but using them is not recommended under Unix and they are
recursive by default. The reason for this is that recursive mutexes are not {\bf not} recursive there by default. The reason for this is that recursive
supported by all Unix flavours and, worse, they cannot be used with mutexes are not supported by all Unix flavours and, worse, they cannot be used
\helpref{wxCondition}{wxcondition}. with \helpref{wxCondition}{wxcondition}. On the other hand, Win32 mutexes are
always recursive.
For example, when several threads use the data stored in the linked list, For example, when several threads use the data stored in the linked list,
modifications to the list should only be allowed to one thread at a time modifications to the list should only be allowed to one thread at a time