apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard <judicat...@gmail.com>
Subject Re: Info about APR threads
Date Wed, 21 Dec 2005 23:11:36 GMT
Thanks a lot your reply was very helpful.
I now see the 3 different types of mutexes: apr_thread mutex, apr_proc mutex
and apr_global mutex.
In my case I want to synchronize both accross threads and accross processes.
That is threadA in processX need to be syncrhonized with threadB in
processY. So I have to use APR global mutex.

I am looking at the docs found on this page:
http://apr.apache.org/docs/apr/group___a_p_r___global_mutex.html#ga1
if you could clarify some questions I have that would be great:

1.) apr_global_mutex_create() should be called only once by the first
process to use the mutex. Then, subsequent processes that want to use the
mutex should call the function apr_global_mutex_child_init().
2.) The pool argument passed to apr_global_mutex_create() and
apr_global_mutex_child_init() in question#1 above is just a regular pool
that is local to each process.
3.) When everything is done, each process has to invoke
apr_global_mutex_destroy().

I have a feeling that this global mutex will be very expensive and is using
some locking involving files.

You are right, my SSL engine is a critical point. The SSL signature will not
be done by a hardware crypto accelerator but by another piece of software.
My SSL engine will batch SSL signatures in a shared queue before sending
them off to the application responsible for crypto services, so that is why
I need some locking on that shared queue of outstanding SSL requests. I am
wondering how SSL engines for hardware crypto accelerators deal with
asynchronous accesses ? I had the feeling that the actual read and write
syscall to the hardware's device driver will take care of serializing the
SSL requests. As a matter of fact, I am now wondering how the default
builtin SSLeay engine deals with concurrency ? My guess is that the default
builtin SSLeay engine does not have to worry about cross-process
concurrency. It only has to deal with cross-thread concurrency and hence can
use the more light-weight apr_thread_mutexes.

Thanks
Richard


On 12/21/05, Nick Kew <nick@webthing.com> wrote:
>
> On Wednesday 21 December 2005 11:09, Richard wrote:
>
> > Now APR pools greatly complicate my situation. If I undestand correctly,
> > apr_thread_mutex_create() needs a pool and the actual mutex will be
> > allocated from that pool.
>
> Yep.
>
> > The location of that pool in memory will not be
> > shared among my processes.
>
> Erm, threads or processes?  If the former, that's moot.  If the latter,
> you would want an APR global mutex.
>
> > So is that a limitation of APR mutexes ? APR
> > mutexes cannot be shared among processes ? Is there a way to get around
> > that ? Is there a hack that could be done by using a special memory
> > allocator for that pool ?
>
> That's why there are three different types of mutex in APR.





> So maybe I should give some background on what I am working on. I am
> > working with Apache, mod_ssl and openssl. Apache is running with the
> worker
> > MPM. I have modified Apache so that the apache processes share a
> > shared-memory buffer (basically setup through a syscall similar to mmap
> > shared).
>
> The conventional Apache way to do that would be with apr_shm.
>
> > I have a special SSL engine that takes care of cerficate
> > signatures. Each apache thread servicing an SSL connection queues the
> > signature request in the shared buffer which is processed by an outside
> > application responsible for encryption. So I need a way to synchronize
> the
> > various threads inside each apache process.
>
> Sounds like the critical point is how you communicate with the external
> application.  Can that be fixed to support asynchronous access?
>
> --
> Nick Kew
>

Mime
View raw message