Mailing List Archive: GnuPG: gcrypt

Faster mutex lock() and unlock()

Index | Next | Previous | View Threaded

haypo at inl

Jul 10, 2006, 5:57 AM

Post #1 of 4 (1658 views)
Permalink

Faster mutex lock() and unlock()

Hi,

I would like to know your opinion about replacing old ath_mutex_lock() with:

int
ath_mutex_lock (ath_mutex_t *lock)
{
if (ops_set)
{
return (*ops.mutex_lock) (lock);
}
else
{
#ifndef NDEBUG
assert (*lock == MUTEX_UNLOCKED);
*lock = MUTEX_LOCKED;
#endif
return 0;
}
}

===> remove "int ret = mutex_init (lock, 1);"

Since currently locking a mutex takes 3 mutex operation:
1. lock(check_init_lock) (and then maybe init mutex)
2. unlock(check_init_lock)
3. lock(mutex)

That's heavy and may cost a lot in multithead environment since
check_init_lock is common to all threads.

I can write the patch to remove mutex_init() call in lock() and unlock(),
which means check all lock() and unlock() calls (to check that mutex is
already initialized). But first I would like to know if you prefer very
strong function, or fast function with a big warning :-) (don't call
lock/unlock before initialize them).

Haypo

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

marcus.brinkmann at ruhr-uni-bochum

Jul 11, 2006, 2:33 AM

Post #2 of 4 (1588 views)
Permalink

Re: Faster mutex lock() and unlock() [In reply to]

At Mon, 10 Jul 2006 14:57:38 +0200 (CEST),
haypo [at] inl wrote:
>
> Hi,
>
> I would like to know your opinion about replacing old ath_mutex_lock() with:

I don't think so :)

We really want static initialization. Furthermore, this would
constitute an API break, which is not acceptable. Look, I think you
are over-engineering. Do you have the profiling data to illustrate
that your proposed changes have any measurable impact in your
application?

Yes, there is a small overhead. The overhead is a lock instruction.
That's significant, but ath was not written for performance, but for
flexibility. If you really need that extra-edge, then you will have
to use a customized solution.

Thanks,
Marcus

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

haypo at inl

Jul 13, 2006, 1:32 AM

Post #3 of 4 (1553 views)
Permalink

Re: Faster mutex lock() and unlock() [In reply to]

Hi,

> haypo [at] inl wrote:
>>
>> I would like to know your opinion about replacing old ath_mutex_lock()
with:
>
> I don't think so
> (...)
> Yes, there is a small overhead. The overhead is a lock instruction.
That's significant, but ath was not written for performance, but for
flexibility
> (...)

Ok, I understand. I don't want to break libgcrypt API/behaviour. I just
try to understand where my program is spending a lot of time, and I have
difficulties to read gprof results ...

Victor Stinner aka haypo

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

nmav at gnutls

Jul 13, 2006, 6:40 AM

Post #4 of 4 (1571 views)
Permalink

Re: Faster mutex lock() and unlock() [In reply to]

On Thu 13 Jul 2006 10:32, Victor Stinner wrote:

> Ok, I understand. I don't want to break libgcrypt API/behaviour. I
> just try to understand where my program is spending a lot of time,
> and I have difficulties to read gprof results ...

I profiled gcrypt and gnutls quite some time ago using a (multithreaded)
https server (on a single cpu system). The profiler I was using was
oprofile. http://oprofile.sourceforge.net/

For libgcrypt the output wasn't really helpful, but I attach it anyway
since it might be usefull to somebody.

regards,
Nikos

Attachments:

gcrypt.out (6.58 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads