| msg43214 - (view) |
Author: Mihai Ibanescu (misa) |
Date: 2003-03-29 16:12 |
| PyThread_acquire_lock can be further optimized to do less locking on the global lock mutex. Original patch location: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86281 |
|
|
| msg43215 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2003-03-30 16:49 |
| Logged In: YES user_id=21627 This looks reasonable to me, but I may be missing something. Tim, can you see a problem with that code? |
|
|
| msg43216 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2003-03-30 22:11 |
| Logged In: YES user_id=31435 Looks fine to me too. Since Python switched to using semaphores on Linux for 2.3, it's unclear that there's a system that uses the condvar code anymore. How will this get tested? |
|
|
| msg43217 - (view) |
Author: Neal Norwitz (nnorwitz) * |
Date: 2003-03-30 22:19 |
| Logged In: YES user_id=33168 _POSIX_SEMAPHORES aren't used if HAVE_BROKEN_POSIX_SEMAPHORES is defined. This currently occurs on Solaris 8 (at least). |
|
|
| msg43218 - (view) |
Author: Mihai Ibanescu (misa) |
Date: 2003-03-31 03:59 |
| Logged In: YES user_id=205865 Also, this happens in 2.2.2 as well (the patch in Red Hat's bugzilla is against 2.2.2 actually). Is there a plan to release a 2.2.3? Is there value in backporting the patch? (should apply cleanly on 2.2.2). |
|
|
| msg43219 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2003-03-31 05:25 |
| Logged In: YES user_id=21627 There are plans to provide Python 2.2.3. I see no problem applying it to 2.2.2, as there shouldn't be any change in visible behaviour. |
|
|
| msg43220 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2003-03-31 17:23 |
| Logged In: YES user_id=31435 I marked this as Accepted, and also don't see any problem with backporting to the 2.2 line. |
|
|
| msg43221 - (view) |
Author: Mihai Ibanescu (misa) |
Date: 2003-03-31 18:21 |
| Logged In: YES user_id=205865 One of the glibc developers expressed some concern on the 2.3 implementation of the global lock using semaphores. I'd be glad to funnel any communication with the glibc community. (you) should do some timings on the current lock implementation vs the one using semaphores. POSIX semaphores have special requirements (e.g., sem_post must be callable in signal handlers) which make semaphores pretty expensive. In NPTL, for instance, sem_post always makes a syscall, there is no userlevel-only path. This makes using semaphores pretty expensive. The same restricting applies in one form or another to all POSIX compliant semaphore implementations. |
|
|
| msg43222 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2003-04-18 11:44 |
| Logged In: YES user_id=21627 Thanks for the patch; committed as thread_pthread.h 2.45 and 2.36.8.3. As for performance: I ran the program import thread, time a = thread.allocate_lock() r = [None]*1000000 for k in range(5): start = time.time() for i in r: a.acquire() a.release() print time.time()-start with standard CVS (semaphores), and it gives 3.0380500555 3.00736105442 3.04938793182 2.99445092678 3.01815795898 With your patch applied, and with defining HAVE_BROKEN_POSIX_SEMAPHORES (so that semaphores are not used anymore), it gives 3.34937000275 3.3407189846 3.55324399471 3.901293993 3.6628960371 So it seems that semphores are indeed more efficient. [Of course, your patch is not relevant for this test, as there is always success] |
|
|