This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug regex/11159] New: lock contention within regexec() when used from multiple threads


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]