On Tuesday 25 October 2005 12:54, Svein Ove Aas wrote:
> > Thread safe by default hash tables should be expensive. The
> > attached test shows that simply adding locking makes (setf gethash)
> > ~1.5 times slower.
> How was this measured? Mutex locks are likely to be considerably more
> expensive on SMP systems, which are becoming more common these days.
The attached test program was run on a single cpu system.
> > However, using a recursive lock that's acquired for the entire
> > test and for each operation the speed penalty is negligible. Of
> > course it puts the burden of clawing back performance on the user
> > like this:
> > (sb-ext:with-locked-hash-table (hash-table)
> > (frob-madly hash-table))
> > or maybe
> > (setf (sb-ext:hash-table-owner hash-table) *current-thread*)
> How about C?
> (sb-ext:with-locked-objects (hash-table other-thingy)
> (frob-madly hash-table)
> (touch-weirdly other-thingy))
To me this looks equivalent to:
Associating a lock with each object a'la java as your example suggests=20
is an idea I don't like: holding a reference to an object and having=20
the ability to lock it should be different things.
> > I prefer A) in the long run, while B) has the endearing quality of
> > being > easily implementable.
> I prefer C, since it has the appeal of generality, but I'd go for B.
> A is right out - increasing hash-table costs by 50% would have people
> writing their own tables just to avoid locking.
I think you have A) and B) mixed up.
> Users should indeed=20
> be capable of grabbing their own locks where required; just make sure
> to specify which operations, if any, are atomic or otherwise
> For the record: My current assumption is that all operations are
> thread-unsafe. It has served me well.
You mean all destructive operations? That's a fine approach to take, but=20
the consequence thread unsafety should not be too severe and gc=20
lossage/deadlock is unacceptable.