Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 54420 invoked from network); 21 Dec 2005 23:12:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Dec 2005 23:12:01 -0000 Received: (qmail 63052 invoked by uid 500); 21 Dec 2005 23:12:00 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 63020 invoked by uid 500); 21 Dec 2005 23:11:59 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 63009 invoked by uid 99); 21 Dec 2005 23:11:59 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2005 15:11:59 -0800 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of judicator3@gmail.com designates 64.233.162.203 as permitted sender) Received: from [64.233.162.203] (HELO zproxy.gmail.com) (64.233.162.203) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2005 15:11:57 -0800 Received: by zproxy.gmail.com with SMTP id 9so270872nzo for ; Wed, 21 Dec 2005 15:11:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=JwG3MCB1qfjQRlMLaq/1MkBoN5h8Jx3wS+xL9Z04LbeC3wYmogOVrjV/25zHBXZsiITGoDEDaN9vI/fUzZ9xrdYZ67uKNuAryKW0SyV42+A9lsI6y1Z1Zk+EHSEaKJwpQq/deJ+a1i6PuHpbdr4PQ+ATb7eUS5tnNEM8Qax0ZII= Received: by 10.36.113.2 with SMTP id l2mr1305642nzc; Wed, 21 Dec 2005 15:11:37 -0800 (PST) Received: by 10.36.134.4 with HTTP; Wed, 21 Dec 2005 15:11:36 -0800 (PST) Message-ID: Date: Wed, 21 Dec 2005 18:11:36 -0500 From: Richard To: Nick Kew Subject: Re: Info about APR threads Cc: dev@apr.apache.org In-Reply-To: <200512211159.40158.nick@webthing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2929_31550519.1135206696969" References: <200512211159.40158.nick@webthing.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_2929_31550519.1135206696969 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks a lot your reply was very helpful. I now see the 3 different types of mutexes: apr_thread mutex, apr_proc mute= x 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 no= t 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 ca= n use the more light-weight apr_thread_mutexes. Thanks Richard On 12/21/05, Nick Kew 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 > ------=_Part_2929_31550519.1135206696969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks a lot your reply was very helpful.
I now see the 3 different types of mutexes: apr_thread mutex, apr_proc mute= x 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<= /a>
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_de= stroy().

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@webthin= g.com> wrote:
On Wednesday 21 December 2005 11:09, Richard wrote:

> Now APR poo= ls greatly complicate my situation. If I undestand correctly,
> apr_t= hread_mutex_create() needs a pool and the actual mutex will be
> allo= cated from that pool.

Yep.

> The location of that pool in memory will not be> shared among my processes.

Erm, threads or processes? &nb= sp;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 c= annot 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
> all= ocator for that pool ?

That's why there are three different types of mutex in APR.


 

&= gt; 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 m= map
> shared).

The conventional Apache way to do that would be= with apr_shm.

> I have a special SSL engine that takes care of cerficate
&g= t; signatures. Each apache thread servicing an SSL connection queues the> signature request in the shared buffer which is processed by an outsi= de
> application responsible for encryption. So I need a way to synchro= nize the
> various threads inside each apache process.

Sounds = like the critical point is how you communicate with the external
applica= tion.  Can that be fixed to support asynchronous access?

--
Nick Kew

------=_Part_2929_31550519.1135206696969--