apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: SMS lock on demand WAS: RE: Possible race condition...
Date Mon, 02 Jul 2001 18:32:46 GMT
Sander Striker wrote:

>Hi,
>
>>Yes, the implementation is straightforward, but not how you paint it. It
>>is actually a lot simpler. I'll present this soon in code. [please be
>>patient :) ]
>>
>
>I'll present pseudo code here to clarify what I was thinking about.
>I'll do the functions first and then explain how it all hangs
>together.
>
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?  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.
  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.

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

--Brian



Mime
View raw message