Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> As we are already fighting hard to avoid new explicit mode-switch use
>>> cases, rather get rid of old ones, I thought it would be better to keep
>>> existing semantic across the fast mutex changes.
>>>
>>> Regarding those sha
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> As we are already fighting hard to avoid new explicit mode-switch use
>> cases, rather get rid of old ones, I thought it would be better to keep
>> existing semantic across the fast mutex changes.
>>
>> Regarding those shared maps: they are per pro
Jan Kiszka wrote:
> As we are already fighting hard to avoid new explicit mode-switch use
> cases, rather get rid of old ones, I thought it would be better to keep
> existing semantic across the fast mutex changes.
>
> Regarding those shared maps: they are per process, aren't they? But here
> we n
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> while preparing my reworked fast mutex patches for submission, reviewing
>> them once again, I realized a conception problem that the fast path can
>> introduce: So far every pthread_mutex_lock or rt_mutex_acquire forced
>> the caller int
Jan Kiszka wrote:
> Hi,
>
> while preparing my reworked fast mutex patches for submission, reviewing
> them once again, I realized a conception problem that the fast path can
> introduce: So far every pthread_mutex_lock or rt_mutex_acquire forced
> the caller into primary mode in case it was in se
