apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: SMS lock on demand WAS: RE: Possible race condition...
Date Mon, 02 Jul 2001 20:37:35 GMT
> Sander Striker wrote:
> [...]
> >Coupling the registration to thread creation, rather than SMS creation,
> >resolves some of the concerns that I listed previously.  But I still have
> >some questions about what happens during alloc/free in this model.
> >Is your plan that the alloc/free functions should check sms->thread_count
> >and do locking if it is greater than 1?
> >
> >
> >No, when the thread_count is increased, the lock is automatically
> >created in the apr_sms_thread_register function.
> >
> >In the code we do this:
> >
> >    if (SMS_XXX_T(sms)->lock)
> >        apr_lock_acquire(SMS_XXX_T(sms)->lock);
> >
> I still count two, or maybe three, race conditions here:
>   * The lock can become non-null between the if-statement and
>     the allocation code that follows (because somebody registers
>     with the SMS from another thread).
>   * In apr_sms_thread_register, two threads can collide in this
>     part:
>         if (!sms->lock) {
>             sms_lock = apr_lock_create();
>         }
>     It's possible for a newly created lock to be leaked in this code.
>   * I'm not sure if the pointer assignment "sms_lock = ..."
>     is going to be atomic on all the supported architectures.
> [...]

The child thread is register in the parent thread. So, in the case of
the first created thread, a lock will be created. This does not happen
in the stub.

I'm working out details, but I'm sure that we can come up with a solid
solution. Expect some commits in about 4 hours.

> >With regard to the addition of parent_sms as an arg to apr_thread_create,
> >am I right in assuming that NULL is valid value (meaning "don't create
> >a stub and don't incur any locking overhead")?
> >
> >
> >No. You need an sms to create your thread structure from. This
> is going to
> >be the parent (ofcourse, this still assumes that pools are going away).
> >In the thread there will be no locking (since there is only one
> registered
> >thread). If the threads sms needs to fall back on its parent, there will
> >be locking involved. To keep this down to a minimum I'm developing the
> >threads sms. It'll be here real soon now(tm).
> >
> >The stub is needed for the thread registration, so it should not be
> >avoided.
> >
> Makes sense to me.

Sorry, you need it for the unregistration and to register the correct
thread with the child sms (only with the child sms).

> Thanks,
> --Brian

View raw message