Ken <[EMAIL PROTECTED]> wrote: > DRH, > > I looked at the memory management code mem3.c. I noticed a > mutex to protect allocations/deallocations and was wondering > what the impact on performance to a multi threaded DB > applicaiton would be?
I guess that depends on your mutex implementation. Or, you could heed my earnest pleas for sanity and *not use threads*. The mutex calls become no-op macros if you compile with -DSQLITE_THREADSAFE=0. Note that mem1.c and mem2.c also have to lock every memory allocation. And every threadsafe implementation of malloc() I've seen locks as well. (How else do you propose to handle a global resource?) > > Other memory allcation schemes seem to allow each thread to > manage memory independently of the other threads. In other > words, the thread would have a hook into its own memory pool > and would not be blocked by any other threads memory requests. > > Some interesting memory managers include: Unfortunately the > first has licensing requirements and the second is copyrighted, > but available for Free. > > http://www.cs.umass.edu/~emery/hoard/screenshot.html > > http://www.garret.ru/~knizhnik/threadalloc/readme.html > We are working on this capability in the mpool fork mentioned in an earlier email today. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
