Pthreads/fr: Difference between revisions

Jump to navigation Jump to search
Created page with "Dans cet exemple basé sur le contenu du fichier thread.c plus haut, access to the standard output channel is serialized - as it normally should be - using a mutex. The call t..."
No edit summary
(Created page with "Dans cet exemple basé sur le contenu du fichier thread.c plus haut, access to the standard output channel is serialized - as it normally should be - using a mutex. The call t...")
Line 110: Line 110:
}
}
}}
}}
In this example, based on the previous code, access to the standard output channel is serialized - as it normally should be - using a mutex. The call to <tt>[http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html pthread_mutex_lock]</tt> is ''blocking'', i.e. the thread will continue to wait indefinitely for the mutex to become available, so you have to take care that no deadlock can occur in your code, that is, that the mutex is guaranteed to become available eventually. This is particularly problematic in a more realistic example where you may have many different mutexes designed to control access to different global data structures. There is also a non-blocking alternative, <tt>[http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html pthread_mutex_trylock]</tt>, which if it fails to obtain the mutex lock returns immediately with a non-zero value indicating that the mutex is busy. You should also ensure that no extraneous code appears inside the serialized code block; since this code will be executed in a serial manner, you want it to be as short as it can safely be in order not to reduce your program's parallel performance.
Dans cet exemple basé sur le contenu du fichier thread.c plus haut, access to the standard output channel is serialized - as it normally should be - using a mutex. The call to <tt>[http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html pthread_mutex_lock]</tt> is ''blocking'', i.e. the thread will continue to wait indefinitely for the mutex to become available, so you have to take care that no deadlock can occur in your code, that is, that the mutex is guaranteed to become available eventually. This is particularly problematic in a more realistic example where you may have many different mutexes designed to control access to different global data structures. There is also a non-blocking alternative, <tt>[http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html pthread_mutex_trylock]</tt>, which if it fails to obtain the mutex lock returns immediately with a non-zero value indicating that the mutex is busy. You should also ensure that no extraneous code appears inside the serialized code block; since this code will be executed in a serial manner, you want it to be as short as it can safely be in order not to reduce your program's parallel performance.


A more subtle form of data synchronization is possible with the read/write lock, <tt>pthread_rwlock_t</tt>. With this construct, multiple threads can simultaneously read the value of a variable but for write access, the read/write lock behaves like the standard mutex, i.e. no other thread may have have any access (read or write) to the variable. Like with a mutex, a <tt>pthread_rwlock_t</tt> must be initialized before its first use and destroyed when it is no longer needed during the program. Individual threads can obtain either a read lock by calling <tt>[http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_rwlock_rdlock.html pthread_rwlock_rdlock]</tt>, or a write lock with <tt>[http://pubs.opengroup.org/onlinepubs/007908775/xsh/pthread_rwlock_wrlock.html pthread_rwlock_wrlock]</tt>. Either one is released using <tt>[http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_rwlock_unlock.html pthread_rwlock_unlock]</tt>.
A more subtle form of data synchronization is possible with the read/write lock, <tt>pthread_rwlock_t</tt>. With this construct, multiple threads can simultaneously read the value of a variable but for write access, the read/write lock behaves like the standard mutex, i.e. no other thread may have have any access (read or write) to the variable. Like with a mutex, a <tt>pthread_rwlock_t</tt> must be initialized before its first use and destroyed when it is no longer needed during the program. Individual threads can obtain either a read lock by calling <tt>[http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_rwlock_rdlock.html pthread_rwlock_rdlock]</tt>, or a write lock with <tt>[http://pubs.opengroup.org/onlinepubs/007908775/xsh/pthread_rwlock_wrlock.html pthread_rwlock_wrlock]</tt>. Either one is released using <tt>[http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_rwlock_unlock.html pthread_rwlock_unlock]</tt>.
rsnt_translations
56,430

edits

Navigation menu