[haiku-commits] Re: BRANCH pdziepak-github.lock_elision [523c8e8] src/system/libroot/os/arch/x86 src/system/libroot/os/locks src/system/libroot/os/arch/x86_64 headers/private/system src/system/libroot/os/arch/ppc
- From: Pawel Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 15 Aug 2013 20:50:35 +0200
2013/8/14 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> On 08/14/2013 05:45 PM, pdziepak-github.lock_elision wrote:
>> status_t arch_system_info_init(struct kernel_args *args);
>> status_t arch_get_system_info(system_info *info, size_t size);
>> +uint32 arch_is_transactional_memory_available(void);
>
>
> Why not bool?
I thought it would cause problem when the header is included in C
files. Apparently, I was wrong.
>> status_t
>> -mutex_lock(mutex *lock)
>> +mutex_lock(mutex* lock)
>> {
>> + // try lock elision first
>> + status_t error = transaction_lock(lock, CheckUnlocked());
>> + if (error == B_OK)
>> + return B_OK;
>> +
>
>
> I don't think doing that unconditionally is a good idea. These are general
> purpose locking functions and a critical section may contain any code. It
> may be too long for transactional execution or it may contain an instruction
> that causes the transaction to abort. In such a case we'd waste cycles
> unnecessarily to execute the code optimistically first.
>
> A good solution may be to introduce explicit mutex_[un]lock_with_elision()
> functions, so developers can decide depending on the critical section
> whether lock elision should be attempted.
I am afraid something like mutex_[un]lock_with_elision() would result
in lock elision almost unused. Besides, the programmers may not know
whether the critical section is or isn't too long or nested too deep
since it is strictly hardware dependent. I think the best solution
would be to make lock implementation to dynamically decide whether to
try lock elision or not (using collected information how many times
transaction was aborted, what was the reason on these aborts, etc), so
that it will be possible to take most of the CPU abilities. In case of
using instructions that always cause aborts inside critical sections
there I think mutex_init_etc() flags may be used to force disabling
(or enabling) lock elision in the particular lock.
Paweł
Other related posts:
