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 19:06:54 GMT
> Thanks!  If I understand this correctly, the only place where the thread
> registration logic is invoked automatically is in thread creation, right?


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

> If so, there are two problems:
>   1. The "sms->thread_count++" operation in the registration function
>     is not guaranteed to be atomic.  So the check of 
> "sms->thread_count > 1"
>     in the alloc/free functions would need to be protected by a lock.

Thought of that :)

>   2. There are some SMS types where no locking is needed even if
>     the thread_count is greater than 1, for example the sms_std that
>     just calls malloc/free.

Yes, there is a distinction between framework locking (used for cleanup
registration, child sms registration) and private sms locking (used
for allocations). The std sms doesn't have the private sms lock.
> 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

> --Brian


View raw message