This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug regex/11159] New: lock contention within regexec() when used from multiple threads
- From: "extproxy at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 11 Jan 2010 09:40:19 -0000
- Subject: [Bug regex/11159] New: lock contention within regexec() when used from multiple threads
- Reply-to: sourceware-bugzilla at sourceware dot org
I have a program that uses multiple threads. Each thread makes heavy use of
regular expression matches by calling the glibc regexec() function.
Unfortunately, this function seems to acquire a global lock - which causes poor
performance in a multi-threaded environment.
I'm not even sure what regexec() needs to lock - it really doesn't need access
to any global state. Maybe it accesses some global locale object or something.
Anyways, it doesn't need to acquire a write lock - a read lock should have
sufficed. Alternatively, a thread-local data structure could be considered.
Hope future releases of glibc can address this performance bug.
--
Summary: lock contention within regexec() when used from multiple
threads
Product: glibc
Version: 2.10
Status: NEW
Severity: normal
Priority: P2
Component: regex
AssignedTo: drepper at redhat dot com
ReportedBy: extproxy at gmail dot com
CC: glibc-bugs-regex at sources dot redhat dot com,glibc-
bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=11159
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.