On Fri, Jun 26, 2009 at 08:22:06PM +1000, Russell Coker wrote:
> /* Internal function that checks whether "impl" is set and if not, sets it to
> * the default. */
> static void impl_check(void)
> {
> CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
> if(!impl)
> impl = &impl_default;
> CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
> }
> /* A macro wrapper for impl_check that first uses a non-locked test before
> * invoking the function (which checks again inside a lock). */
> #define IMPL_CHECK if(!impl) impl_check();
>
> So if we changed the macro definition to the following then the problem would
> go away:
>
> #define IMPL_CHECK impl_check();
>
> But that would probably decrease performance. Is there a possibility of a
> pointer write not being atomic?
The answer to that question is very CPU specific. There is no
guarantee that it is atomic. And I'm not even sure that being
atomic is a good enough guarantee. You probably also need
to prevent reordering (with barriers).
Looking at the Linux kernel, they have a define/function
atomic_set() just to be able to write a integer atomicly on all
arches it supports. There is also an atomic_read().
Looking at this example, impl could be in the process of being
written in thread 1, but only half written, and then thread 2's
"if (!impl)" could fail and it might call impl() with a wrong
pointer. It's probably unlikely that this happens, but it
always bites you sooner or later.
Kurt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
