> 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
>
>
>
>
>
