On Thursday, December 27, 2018 at 9:55:57 PM UTC-8, Artur Brugeman wrote:
>
> Hi Chris,
>
> Thank you for your thoughts on this, my thinking was in line with yours
> and that's why I tried to add timed waiting in Dmitry's eventcount. I guess
> I need to spend some more time there and figure it out.
>
Iirc, Dmitrys algo used some per-thread waitsets for an eventcount algo.
Cannot remember right now if it is the same one you are referring to.
Fwiw, one can even spin on the lock for wait_begin, wrt something like:
________________
bool wait_begin_try()
{
if (! m_mutex.try_lock($)) return false;
m_waitbit.store(1, CT_MB_RLX);
CT_MB(CT_MB_SEQ_CST);
return true;
}
________________
The predicate loop can look like:
________________
unsigned int signal = 0;
while ((signal = m_signal.load(CT_MB_RLX)) != 2)
{
if (! g_ecount.wait_begin_try())
{
rl::yield(1, $);
continue;
}
signal = m_signal.load(CT_MB_RLX);
if (signal == 2)
{
g_ecount.wait_cancel();
break;
}
g_ecount.wait_commit();
}
________________
It can even be adaptive in nature where one can fail the try_lock a couple
of times, then just lock the sucker!
;^)
>
>
> On Friday, December 28, 2018 at 4:32:04 AM UTC+5, Chris M. Thomasson wrote:
>>
>> On Sunday, December 23, 2018 at 9:30:03 PM UTC-8, Artur Brugeman wrote:
>>>
>>> Hi Dmitry,
>>>
>>> I want to use your eventcount (took the source from intel forum).
>>>
>>> Currently I was using semaphores, which allowed me to set waiting
>>> timeout.
>>>
>>> Questions:
>>> 1. Is the source from intel forum 'the latest and stable'? You had a
>>> pretty long discussion there and I'm not sure the posted sources
>>> incorporated all the fixes.
>>> 2. Can eventcount support waiting timeouts? Can I just add 'timeout'
>>> param to prepare_wait and commit_wait and call 'sema.timedwait' instead of
>>> 'wait'? In fact I did just that and now I get segfaults here and there, so
>>> not sure it's the way to go.
>>>
>>> Can you please share your thoughts on this?
>>>
>>> Thanks a lot!
>>>
>>>
>> Fwiw, a timed wait on an eventcount works as easily as spinning on it wrt
>> not waiting on a kernel waitset at all. The predicate is the user algorithm
>> itself. So, imagine if the waits never actually block, but spin around.
>> Yet, everything still works. Fwiw, the following code, that should compile
>> with Relacy, is the most simplistic eventcount I can imagine:
>> _________________________________
>> ...............
>>
>> think if g_ecount.wait_commit(); was timed... It would still work as is.
>> So, yes an eventcount can easily handle timed waits.
>>
>
--
---
You received this message because you are subscribed to the Google Groups
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lock-free/b67bbb52-d353-416e-85fa-7399c69e9349%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
