On 06/11/2014 02:26 PM, Salz, Rich wrote:
What kinds of operations are protected by read locks?
Looking at almost any of the global data structures, such as error tables, OID
tables, and so on.
Often, RW locks aren't a win because maintaining just the read locks (without
any writers)
..@redhat.com>
Sent by: owner-openssl-...@openssl.orgDate: 06/12/2014 06:23PM
Subject: Re: Locking inefficiency
On 06/11/2014 02:26 PM, Salz, Rich wrote: What kinds of operations are protected by read locks?
Looking at almost any of the global data structures, such as error tables, OID tables, a
Ø Preload them all at startup with a global lock held, delete them at shutdown
with a global lock held. If all the other access is 'read' the structures don't
need a lock between times.
Ø Might be something to consider putting on the to do list. I can understand
things being done like that
: Geoffrey Thorpe [mailto:ge...@geoffthorpe.com]
Sent: Monday, June 09, 2014 10:13 PM
To: openssl-dev@openssl.org
Cc: Levin, Igor; Salz, Rich
Subject: Re: Locking inefficiency
Hey Bodo,
On Mon, Jun 9, 2014 at 3:15 PM, Bodo Moeller
bmoel...@acm.orgmailto:bmoel...@acm.org wrote:
Geoffrey Thorpe ge
On Tue, Jun 10, 2014 at 3:27 PM, Levin, Igor ile...@akamai.com wrote:
Geoff,
we did not seem to be able to figure out what openssl Makefile actually
builds crypto/threads/th-lock.c
In our particular case we explicitly included that file when building our
server, but for
ot;Salz, Rich" rs...@akamai.com
Subject: Re: Locking inefficiency
On Tue, Jun 10, 2014 at 3:27 PM, Levin, Igor
ile...@akamai.com
wrote:
Geoff,
we did not seem to be able to figure out what openssl Makefile actually builds crypto/threads/th-lock.c
In our particular case we explicitly
On 06/10/2014 03:31 PM, Bodo Moeller wrote:
The way we use the locks, in heavily multi-threaded applications, you
can have a lot of contention with mutexes that wouldn't exist with
read/write locks, because often all threads would only require the read
locks
What kinds of operations are
On 06/11/2014 10:24 AM, Peter Waltenberg wrote:
The one we (IBM) hit is composite apps. Multiple independently developed
lumps of code thrown together - someone has to set the locks, but
deciding who is a problem. We deal with it easily as we put a wrapper
around OpenSSL and do it there, but
What kinds of operations are protected by read locks?
Looking at almost any of the global data structures, such as error tables, OID
tables, and so on.
Often, RW locks aren't a win because maintaining just the read locks (without
any writers) introduces contention at the hardware level, and
11, 2014 8:26 AM
To: openssl-dev@openssl.org
Cc: Levin, Igor
Subject: RE: Locking inefficiency
What kinds of operations are protected by read locks?
Looking at almost any of the global data structures, such as error tables, OID
tables, and so on.
Often, RW locks aren't a win because maintaining
Geoffrey Thorpe ge...@geoffthorpe.com:
So I'm going to propose that we initially put this patch into the
development head only, and defer a decision on whether to cherry-pick it
into stable branches until that testing is in place.
Sure, sounds right. (Will you go ahead and handle the patch?)
On Mon, Jun 09, 2014 at 09:15:15PM +0200, Bodo Moeller wrote:
Geoffrey Thorpe ge...@geoffthorpe.com:
First, you're right, pthreads_locking_callback() is collapsing everything
to a mutex.
I was well aware of this and thought we did this for compatibility reasons
(because I couldn't
Thor, can you quantify what you mean by much more expensive? (And
qualify it - what platform, what operations?)
The way we use the locks, in heavily multi-threaded applications, you can
have a lot of contention with mutexes that wouldn't exist with read/write
locks, because often all threads
It has been a while since I looked at this code, and I'd forgotten some of
the convolution implicit in the pluggability of the ERR API. Something
else for the TODO list I guess. I doubt that anyone is making use of that
flexibility, and it would be massively simpler to carve it down to a single
Geoffrey Thorpe ge...@geoffthorpe.com:
First, you're right, pthreads_locking_callback() is collapsing everything
to a mutex.
I was well aware of this and thought we did this for compatibility reasons
(because I couldn't think of any other reasonable explanation, I guess).
If actual read-write
Hey Bodo,
On Mon, Jun 9, 2014 at 3:15 PM, Bodo Moeller bmoel...@acm.org wrote:
Geoffrey Thorpe ge...@geoffthorpe.com:
First, you're right, pthreads_locking_callback() is collapsing everything
to a mutex.
I was well aware of this and thought we did this for compatibility reasons
(because
16 matches
Mail list logo
