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 00:59:03 GMT
> 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.

Whoops. Guess I didn't explain how it all hung together.
The framework(apr) is to call apr_sms_thread_register()
whenever a new thread is created. The framework is also
responsible for calling apr_sms_thread_unregister whenever
a thread dies.

A simple example (using a before and after sms hierarchy).
Before:

        ...
         | thread 1
         |
        sms A (count 1)
         |
         |
        sms B (count 1)

After newly created thread:

        ...
         | thread 1
         |
        sms A (count 2)
         |
         |
        sms B (count 2)
         |
         |
         +--- ...
         | thread 2
         |
        sms C (count 1)

As can be read from the pseudo code in the
previous mail, A and B now perform locking and
C doesn't.

To allow an application to use an sms in another
thread it knows about, the programmer can call
apr_sms_thread_register(known_sms, os_thread_current())
to show interest manually. Ofcourse, when this
is done the programmer is also responsible for calling
apr_sms_thread_unregister().
This should only occur by exception, not by rule.
I can imagine though that there might be one
global shared memory sms (when we get around to
that) which multiple threads are to use.

Hope this clarifies things a bit more.

Sander


Mime
View raw message