apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject SMS lock on demand WAS: RE: Possible race condition...
Date Mon, 02 Jul 2001 00:45:36 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.

apr_sms_thread_register(sms, os_thread)
{
    if (!sms->lock) {
        sms->lock = apr_lock_create();
    }

    apr_lock_acquire(sms->lock);

    sms->thread_count++;

    /* let the sms know about the thread if it is
     * interested (so it can protect its private
     * data with its own lock)
     */
    if (sms->thread_register_fn)
        sms->thread_register_fn(os_thread);

    pms = sms->parent;
    while (pms) {
       apr_sms_thread_register(os_thread);
       pms = pms->parent;
    }

    apr_lock_release(sms->lock);
}

apr_sms_init(sms, parent)
{
    ...

    sms->thread_count = 1;

    ...
}

apr_sms_post_init(sms)
{
    ...    

    if (sms->thread_register_fn)
        sms->thread_register_fn(apr_os_thread_current());
}

apr_thread_create(..., parent_sms, ...)
{
    ...
    
    [don't know how this is going to fit together in detail
     yet. probably need to call the worker thread function
     from a stub, and put the child pool creation in the stub* ]
    
    os_thread = apr_thread_create(stub, stub_data, SUSPENDED);

    apr_sms_thread_register(parent_sms, os_thread);

    apr_thread_resume(thread);

    ...
}

*) The structure of the stub:

stub(stub_data)
{
   sms = apr_sms_trivial_create(stub_data->parent_sms);

   stub_data->thread_fn(stub_data->thread_data);

   apr_sms_thread_unregister(apr_os_thread_current());
}

Like I said, pseudo. I hope you get and the idea on the lock
creation and the threads showing interest in an sms. Also
note that in the framework and most of the smss the os_thread
parameter can be ignored. Counting is enough. As an initial
implementation the apr_sms_unregister function could just
decrease sms->thread_count, lock destruction has some
difficulties that have to be resolved.

Sander

PS. Using a stub for the thread function could be usefull
    to implement suspended thread creation on platforms
    that don't support that natively (if any).


Mime
View raw message