@@ -849,30 +849,6 @@ static int running_on_valgrind = -1;
849849
850850/*==========================================================================*/
851851
852- /*
853- * Locking
854- *
855- * To reduce lock contention, it would probably be better to refine the
856- * crude function locking with per size class locking. I'm not positive
857- * however, whether it's worth switching to such locking policy because
858- * of the performance penalty it might introduce.
859- *
860- * The following macros describe the simplest (should also be the fastest)
861- * lock object on a particular platform and the init/fini/lock/unlock
862- * operations on it. The locks defined here are not expected to be recursive
863- * because it is assumed that they will always be called in the order:
864- * INIT, [LOCK, UNLOCK]*, FINI.
865- */
866-
867- /*
868- * Python's threads are serialized, so object malloc locking is disabled.
869- */
870- #define SIMPLELOCK_DECL (lock ) /* simple lock declaration */
871- #define SIMPLELOCK_INIT (lock ) /* allocate (if needed) and initialize */
872- #define SIMPLELOCK_FINI (lock ) /* free/destroy an existing lock */
873- #define SIMPLELOCK_LOCK (lock ) /* acquire released lock */
874- #define SIMPLELOCK_UNLOCK (lock ) /* release acquired lock */
875-
876852/* When you say memory, my mind reasons in terms of (pointers to) blocks */
877853typedef uint8_t block ;
878854
@@ -944,15 +920,6 @@ struct arena_object {
944920
945921/*==========================================================================*/
946922
947- /*
948- * This malloc lock
949- */
950- SIMPLELOCK_DECL (_malloc_lock )
951- #define LOCK () SIMPLELOCK_LOCK(_malloc_lock)
952- #define UNLOCK () SIMPLELOCK_UNLOCK(_malloc_lock)
953- #define LOCK_INIT () SIMPLELOCK_INIT(_malloc_lock)
954- #define LOCK_FINI () SIMPLELOCK_FINI(_malloc_lock)
955-
956923/*
957924 * Pool table -- headed, circular, doubly-linked lists of partially used pools.
958925
@@ -1381,7 +1348,6 @@ pymalloc_alloc(void *ctx, void **ptr_p, size_t nbytes)
13811348 return 0 ;
13821349 }
13831350
1384- LOCK ();
13851351 /*
13861352 * Most frequent paths first
13871353 */
@@ -1537,13 +1503,11 @@ pymalloc_alloc(void *ctx, void **ptr_p, size_t nbytes)
15371503 goto init_pool ;
15381504
15391505success :
1540- UNLOCK ();
15411506 assert (bp != NULL );
15421507 * ptr_p = (void * )bp ;
15431508 return 1 ;
15441509
15451510failed :
1546- UNLOCK ();
15471511 return 0 ;
15481512}
15491513
@@ -1612,8 +1576,6 @@ pymalloc_free(void *ctx, void *p)
16121576 }
16131577 /* We allocated this address. */
16141578
1615- LOCK ();
1616-
16171579 /* Link p to the start of the pool's freeblock list. Since
16181580 * the pool had at least the p block outstanding, the pool
16191581 * wasn't empty (so it's already in a usedpools[] list, or
@@ -1798,7 +1760,6 @@ pymalloc_free(void *ctx, void *p)
17981760 goto success ;
17991761
18001762success :
1801- UNLOCK ();
18021763 return 1 ;
18031764}
18041765
0 commit comments