gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A question on discardEventsMatchingMask:beforeEvent:


From: SPUeNTRUP - Kai Henningsen
Subject: Re: A question on discardEventsMatchingMask:beforeEvent:
Date: Mon, 31 Jan 2011 10:51:14 +0100

Hallo Richard,

Am Fri, 28 Jan 2011 15:33:57 +0000
schrieb Richard Frith-Macdonald <address@hidden>:

> When I was looking at it, I found it hard to see how best to make a fast 
> allocation/deallocation scheme thread-safe.

I learned this from ptmalloc3. The comment explaining the central idea
is this:

/* arena_get() acquires an arena and locks the corresponding mutex.
 * First, try the one last locked successfully by this thread.  (This
 * is the common case and handled with a macro for speed.)  Then, loop
 * once over the circularly linked list of arenas.  If no arena is
 * readily available, create a new one.  In this latter case, `size'
 * is just a hint as to how much memory will be required immediately
 * in the new arena. */

Of course, when you need to free(), you have to get the arena you
allocated from. But you usually do not have to contend with two dozen
threads who want to use the same arena. In fact, lock conflicts are
extremely rare with this scheme. (Oh, searching the arena list for a
free arena needs to be locked against creating a new arena. But
remember that you usually can just use the same arena as last time,
especially if you do lots of allocations. Also, you need a very short
lock for marking the arena busy. Or just look at how ptmalloc3 does
it!)

This stuff is FAST.

Mit freundlichen Grüßen aus Münster /
with kind regards - Kai Henningsen

-- 
SPUeNTRUP Software
An der Kleimannbrücke 52
D-48157 Münster, Germany

Reg:    Münster Nr.29047

Fon:    +49 700 CALL CATS (=22552287)
Fon:    +49 251 322 311 0
Fax:    +49 251 322 311 99

Web:    http://www.cats.ms
Mail:   address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]