In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Am 23.09.2021 um 19:38 schrieb Chris M. Thomasson:Oh, I just thought that those two moves can be dropped since thei're
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Please, try it out in a race detector? Create several programs that
use your code in high load scenarios, and see what happens in the
detector. Do we all have the time to examine your "tricky" code and
test it out for ourselves? Well, not really. I am fairly busy with
some fractal work right now. Sorry Bonita.
Not necessary. My montor works perfectly.
I've implemented something completely new: a poll_wait operation.
You simply supply a check-lambda that checks if there is valid state
and my code repeatedly tries to lock the lock and check if the con-
dition is true. The number of spins is re-calculated at each call
according to the recalculation-pattern of the glibc.
template<typename RetType, typename Predicate>
requires requires( Predicate pred )
{
{ pred() } -> std::same_as<std::pair<bool, RetType>>;
}
RetType monitor::wait_poll( Predicate const &pred )
{
using namespace std;
using retpair_t = pair<bool, RetType>;
uint32_t maxSpinT = (uint32_t)m_nextPollSpinCount * 2 + 10;
uint16_t maxSpin = maxSpinT <= m_maxPollSpinCount ? (uint16_t)maxSpinT : m_maxPollSpinCount,
spinCount = 0;
bool notify = false;
uint64_t cmp = m_flagAndCounters.load( memory_order_relaxed );
for( ; !notify && spinCount < maxSpin; ++spinCount )
if( isOwned( cmp ) )
{
cpu_pause( PAUSE_ITERATIONS );
cmp = m_flagAndCounters.load( memory_order_relaxed );
continue;
}
else if( m_flagAndCounters.compare_exchange_weak( cmp, cmp | OWNER_MASK, memory_order_acquire, memory_order_relaxed ) )
{
retpair_t ret = move( pred() );
uint64_t chg;
do
{
uint32_t visitors = getVisitors( cmp ),
waiters = getWaiters( cmp );
assert(visitors >= waiters);
chg = cmp & ~OWNER_MASK;
if( notify = visitors > waiters )
chg -= VISITOR_VALUE;
} while( !m_flagAndCounters.compare_exchange_weak( cmp,
chg, memory_order_relaxed, memory_order_relaxed ) );
if( notify )
#if defined(_MSC_VER)
while( !SetEvent( (HANDLE)m_xhEvtVisit ) ); #elif defined(__unix__)
for( m_sems( { sembuf( VISITOR_SEM, 1, 0 ) }, false )
== -1 );
#endif
if( !ret.first )
if( !notify )
continue;
else
break;
if( !notify )
m_nextPollSpinCount += (int16_t)(((int32_t)spinCount -
(int32_t)m_nextPollSpinCount) / 8);
return move( ret.second );
}
else
cpu_pause( PAUSE_ITERATIONS );
if( !notify )
m_nextPollSpinCount += (int16_t)(((int32_t)spinCount - (int32_t)m_nextPollSpinCount) / 8);
lock();
try
{
for( ; ; )
{
retpair_t ret = move( pred() );
if( ret.first )
{
unlock();
return move( ret.second );
}
wait();
}
}
catch( ... )
{
unlock();
throw;
}
}
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Please, try it out in a race detector? Create several programs that use
your code in high load scenarios, and see what happens in the detector.
Do we all have the time to examine your "tricky" code and test it out
for ourselves? Well, not really. I am fairly busy with some fractal work right now. Sorry Bonita.
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar impls that
used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It exists mainly for backward compatibility. For more information, see Remarks."
Am 25.09.2021 um 03:56 schrieb Chris M. Thomasson:
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar impls that
used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It exists
mainly for backward compatibility. For more information, see Remarks."
What I do is reliable.
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
Am 25.09.2021 um 03:56 schrieb Chris M. Thomasson:
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar impls that
used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It exists
mainly for backward compatibility. For more information, see Remarks."
What I do is reliable.
This is because you SAY SO?
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
Show your code, I missed it :(What I do is reliable.
This is because you SAY SO?
Inspect my code and say why it is not instead of making
arbitrary assumptions.
What I do is reliable.
This is because you SAY SO?
Inspect my code and say why it is not instead of making
arbitrary assumptions.
Am 25.09.2021 um 15:59 schrieb Branimir Maksimovic:
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
Show your code, I missed it :(What I do is reliable.
This is because you SAY SO?
Inspect my code and say why it is not instead of making
arbitrary assumptions.
I showed my wait_poll-function. It's sth. completely new that improves
most usualy monitor-handling, usually with producer-consumer patterns
where the mutex-part of the monitor is held very short.
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
Am 25.09.2021 um 15:59 schrieb Branimir Maksimovic:
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
Show your code, I missed it :(What I do is reliable.
This is because you SAY SO?
Inspect my code and say why it is not instead of making
arbitrary assumptions.
I showed my wait_poll-function. It's sth. completely new that improves
most usualy monitor-handling, usually with producer-consumer patterns
where the mutex-part of the monitor is held very short.
And you use unreliable function for that?
I am just asking because you build something
And you use unreliable function for that?
Show me where my code is unreliable.
I think you're simply a poor troll.
Am 25.09.2021 um 03:56 schrieb Chris M. Thomasson:
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar impls
that used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It
exists mainly for backward compatibility. For more information, see
Remarks."
What I do is reliable.
On 9/24/2021 10:24 PM, Bonita Montero wrote:
Am 25.09.2021 um 03:56 schrieb Chris M. Thomasson:
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar impls
that used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It
exists mainly for backward compatibility. For more information, see
Remarks."
What I do is reliable.
Whats up with the:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Shouldn't you use GetLastError to find out why SetEvent failed?
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
I am just asking because you build something
And you use unreliable function for that?
Show me where my code is unreliable.
I think you're simply a poor troll.
on shaken ground. Why do you think is reliable,
simple question?
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
{
uint64_t cmp = m_flagAndCounters.load( memory_order_relaxed ), chg;
uint32_t visitors, aWaiters, bWaiters, waiters;
assert(m_tid == thread_id::self());
m_tid = thread_id();
do
{
assert(isOwned( cmp ) && !m_recCount);
visitors = getVisitors( cmp );
aWaiters = getAWaiters( cmp );
bWaiters = getAWaiters( cmp );
assert(visitors >= aWaiters + bWaiters);
waiters = !b ? aWaiters : bWaiters;
static
char const *const throwTable[] =
{
nullptr /* 0000 */, nullptr /* 0001 */, nullptr /* 0010 */,
nullptr /* 0011 */, nullptr /* 0100 */, nullptr /* 0101 */,
"monitor::wait() - number of visitors and a-waiters too
large", // 0110
"monitor::wait() - number of visitors and a-waiters too
large", // 0111
nullptr /* 1000 */, nullptr /* 1001 */, nullptr /* 1010 */,
nullptr /* 1011 */, nullptr /* 1100 */,
"monitor::wait() - number of visitors and b-waiters too
large", // 1101
nullptr, // 1110
"monitor::wait() - number of visitors and b-waiters too
large", // 1111
};
size_t maxVisitors = visitors == COUNTER_MASK,
maxAWaiters = aWaiters == COUNTER_MASK,
maxBWaiters = bWaiters == COUNTER_MASK;
size_t throwIdx = (size_t)b << 3 | maxVisitors << 2 | maxAWaiters << 1 | maxBWaiters;
if( throwTable[throwIdx] )
{
m_tid = thread_id::self();
throw out_of_range( throwTable[throwIdx] );
};
if( visitors > waiters )
// waiters < COUNTER_MASK because visitors > waiters
// taking over visitor-counter from another thread
chg = cmp + (!b ? WAITER_A_VALUE : WAITER_B_VALUE);
else
// visitors == aWaiters + bWaiters
chg = (cmp & ~OWNER_MASK) + (!b ? WAITER_A_VALUE : WAITER_B_VALUE) + VISITOR_VALUE;
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, memory_order_release, memory_order_relaxed ) );
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
{
uint64_t cmp = m_flagAndCounters.load( memory_order_relaxed ), chg;
uint32_t visitors, aWaiters, bWaiters, waiters;
assert(m_tid == thread_id::self());
m_tid = thread_id();
do
{
assert(isOwned( cmp ) && !m_recCount);
visitors = getVisitors( cmp );
aWaiters = getAWaiters( cmp );
bWaiters = getAWaiters( cmp );
assert(visitors >= aWaiters + bWaiters);
waiters = !b ? aWaiters : bWaiters;
static
char const *const throwTable[] =
{
nullptr /* 0000 */, nullptr /* 0001 */, nullptr /* 0010 */,
nullptr /* 0011 */, nullptr /* 0100 */, nullptr /* 0101 */,
"monitor::wait() - number of visitors and a-waiters too
large", // 0110
"monitor::wait() - number of visitors and a-waiters too
large", // 0111
nullptr /* 1000 */, nullptr /* 1001 */, nullptr /* 1010 */,
nullptr /* 1011 */, nullptr /* 1100 */,
"monitor::wait() - number of visitors and b-waiters too
large", // 1101
nullptr, // 1110
"monitor::wait() - number of visitors and b-waiters too
large", // 1111
};
size_t maxVisitors = visitors == COUNTER_MASK,
maxAWaiters = aWaiters == COUNTER_MASK,
maxBWaiters = bWaiters == COUNTER_MASK;
size_t throwIdx = (size_t)b << 3 | maxVisitors << 2 |
maxAWaiters << 1 | maxBWaiters;
if( throwTable[throwIdx] )
{
m_tid = thread_id::self();
throw out_of_range( throwTable[throwIdx] );
};
if( visitors > waiters )
// waiters < COUNTER_MASK because visitors > waiters
// taking over visitor-counter from another thread >> chg = cmp + (!b ? WAITER_A_VALUE : WAITER_B_VALUE); >> else
// visitors == aWaiters + bWaiters
chg = (cmp & ~OWNER_MASK) + (!b ? WAITER_A_VALUE : >> WAITER_B_VALUE) + VISITOR_VALUE;
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg,
memory_order_release, memory_order_relaxed ) );
Humm... For some reason I feel the need for std::memory_order_acq_rel
here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
On 9/27/2021 5:44 AM, Bonita Montero wrote:
[redacted]
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
If you're going to ask for opinions and then reject any criticism
as nonsense, then why the heck are you even bothering to post your
code?
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg,[...]
memory_order_release, memory_order_relaxed ) );
Humm... For some reason I feel the need for std::memory_order_acq_rel
here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>> be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for std::memory_order_acq_rel
here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics. Incrementing a
semaphore requires release semantics. Trying to do both at once in a
single atomic operation requires acquire/release semantics.
I still need to port it to Relacy, but it seems like you need acq_rel here.
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>> be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for std::memory_order_acq_rel
here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics.
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception
might
be thrown. These states are all true or false so I combined them to a >>>>> four bit pattern wich I used as an index to a table which stores the >>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>> state isn't associated with an out of range condition. This helps me >>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the >>>>> code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics. Incrementing a
semaphore requires release semantics. Trying to do both at once in a
single atomic operation requires acquire/release semantics.
I still need to port it to Relacy, but it seems like you need acq_rel
here.
Think about it... Waiting for something, implies acquire semantics.
Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson:
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception
might
be thrown. These states are all true or false so I combined them to a >>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>> state isn't associated with an out of range condition. This helps me >>>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the >>>>>> code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics. Incrementing a
semaphore requires release semantics. Trying to do both at once in a
single atomic operation requires acquire/release semantics.
I still need to port it to Relacy, but it seems like you need acq_rel
here.
Think about it... Waiting for something, implies acquire semantics.
No, when I release a lock and could have modified data,
I need release-semantics.
Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception
might
be thrown. These states are all true or false so I combined them to a >>>>> four bit pattern wich I used as an index to a table which stores the >>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>> state isn't associated with an out of range condition. This helps me >>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the >>>>> code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics.
No, I could have modified data before, so I need, release-semantics.
You are such a n00b.
Am 25.09.2021 um 22:34 schrieb Chris M. Thomasson:
On 9/24/2021 10:24 PM, Bonita Montero wrote:
Am 25.09.2021 um 03:56 schrieb Chris M. Thomasson:
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar impls
that used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It
exists mainly for backward compatibility. For more information, see
Remarks."
What I do is reliable.
Whats up with the:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Shouldn't you use GetLastError to find out why SetEvent failed?
No, once I incremented the waiter or visitor count I can't set it back because it might have been reduced by someone awakening me. So I've to
spin or terminate the program.
But this doesn't matter since SE fails
under conditions where the machine almost has no resources.
On 9/27/2021 9:55 PM, Bonita Montero wrote:
Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception
might
be thrown. These states are all true or false so I combined them to a >>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>> state isn't associated with an out of range condition. This helps me >>>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the >>>>>> code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics.
No, I could have modified data before, so I need, release-semantics.
You are such a n00b.
For some reason when I saw the word "wait", I think of acquire. Are you
sure you know all about memory barriers? I have worked with them in the
past.
On 9/27/2021 9:57 PM, Bonita Montero wrote:
Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson:
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception >>>>>>> might
be thrown. These states are all true or false so I combined them >>>>>>> to a
four bit pattern wich I used as an index to a table which stores the >>>>>>> strings of the out_of_range exception to be trown or a nullptr if >>>>>>> the
state isn't associated with an out of range condition. This helps me >>>>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around >>>>>>> the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics. Incrementing a
semaphore requires release semantics. Trying to do both at once in a
single atomic operation requires acquire/release semantics.
I still need to port it to Relacy, but it seems like you need
acq_rel here.
Think about it... Waiting for something, implies acquire semantics.
No, when I release a lock and could have modified data,
I need release-semantics.
So, how can one utilize dual_monitor::wait? Does it wait on something?
On 9/25/2021 8:48 PM, Bonita Montero wrote:
Am 25.09.2021 um 22:34 schrieb Chris M. Thomasson:
On 9/24/2021 10:24 PM, Bonita Montero wrote:
Am 25.09.2021 um 03:56 schrieb Chris M. Thomasson:
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar impls
that used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It
exists mainly for backward compatibility. For more information, see
Remarks."
What I do is reliable.
Whats up with the:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Shouldn't you use GetLastError to find out why SetEvent failed?
No, once I incremented the waiter or visitor count I can't set it back
because it might have been reduced by someone awakening me. So I've to
spin or terminate the program.
Terminate? Humm... If there are conditions arising in the system in
which SetEvent fails, you go into infinite loop here, right? Try to
handle this scenario. Find out why it failed, GetLastError.
Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson:
On 9/27/2021 9:57 PM, Bonita Montero wrote:
Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson:
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an
exception might
be thrown. These states are all true or false so I combined them >>>>>>>> to a
four bit pattern wich I used as an index to a table which stores >>>>>>>> the
strings of the out_of_range exception to be trown or a nullptr >>>>>>>> if the
state isn't associated with an out of range condition. This
helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines
around the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>> chg, memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics. Incrementing a
semaphore requires release semantics. Trying to do both at once in
a single atomic operation requires acquire/release semantics.
I still need to port it to Relacy, but it seems like you need
acq_rel here.
Think about it... Waiting for something, implies acquire semantics.
No, when I release a lock and could have modified data,
I need release-semantics.
So, how can one utilize dual_monitor::wait? Does it wait on something?
Its like waiting on a condvar, which might have modified any data
before.
Am 28.09.2021 um 07:46 schrieb Chris M. Thomasson:
On 9/25/2021 8:48 PM, Bonita Montero wrote:
Am 25.09.2021 um 22:34 schrieb Chris M. Thomasson:
On 9/24/2021 10:24 PM, Bonita Montero wrote:
Am 25.09.2021 um 03:56 schrieb Chris M. Thomasson:
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar impls >>>>>> that used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It
exists mainly for backward compatibility. For more information,
see Remarks."
What I do is reliable.
Whats up with the:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Shouldn't you use GetLastError to find out why SetEvent failed?
No, once I incremented the waiter or visitor count I can't set it back
because it might have been reduced by someone awakening me. So I've to
spin or terminate the program.
Terminate? Humm... If there are conditions arising in the system in
which SetEvent fails, you go into infinite loop here, right? Try to
handle this scenario. Find out why it failed, GetLastError.
If the system hasn't any resources to satisfy a simple WaitForSingle... spinning is quite o.k..
Am 28.09.2021 um 07:27 schrieb Chris M. Thomasson:
On 9/27/2021 9:55 PM, Bonita Montero wrote:
Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception >>>>>>> might
be thrown. These states are all true or false so I combined them >>>>>>> to a
four bit pattern wich I used as an index to a table which stores the >>>>>>> strings of the out_of_range exception to be trown or a nullptr if >>>>>>> the
state isn't associated with an out of range condition. This helps me >>>>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around >>>>>>> the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics.
No, I could have modified data before, so I need, release-semantics.
You are such a n00b.
For some reason when I saw the word "wait", I think of acquire. Are
you sure you know all about memory barriers? ...
Everything necessary here.
On 9/27/2021 11:34 PM, Bonita Montero wrote:
Am 28.09.2021 um 07:46 schrieb Chris M. Thomasson:
On 9/25/2021 8:48 PM, Bonita Montero wrote:
Am 25.09.2021 um 22:34 schrieb Chris M. Thomasson:
On 9/24/2021 10:24 PM, Bonita Montero wrote:
Am 25.09.2021 um 03:56 schrieb Chris M. Thomasson:
On 9/24/2021 6:48 PM, Chris M. Thomasson wrote:
On 9/23/2021 11:29 AM, Bonita Montero wrote:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Humm....
For some damn reason, this reminds me of some broken condvar
impls that used the good ol' PulseEvent:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent
A quote: "This function is unreliable and should not be used. It >>>>>>> exists mainly for backward compatibility. For more information,
see Remarks."
What I do is reliable.
Whats up with the:
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Shouldn't you use GetLastError to find out why SetEvent failed?
No, once I incremented the waiter or visitor count I can't set it back >>>> because it might have been reduced by someone awakening me. So I've to >>>> spin or terminate the program.
Terminate? Humm... If there are conditions arising in the system in
which SetEvent fails, you go into infinite loop here, right? Try to
handle this scenario. Find out why it failed, GetLastError.
If the system hasn't any resources to satisfy a simple WaitForSingle...
spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full speed! while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
On 9/27/2021 11:33 PM, Bonita Montero wrote:
Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson:
On 9/27/2021 9:57 PM, Bonita Montero wrote:
Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson:
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an
exception might
be thrown. These states are all true or false so I combined
them to a
four bit pattern wich I used as an index to a table which
stores the
strings of the out_of_range exception to be trown or a nullptr >>>>>>>>> if the
state isn't associated with an out of range condition. This
helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines
around the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>>> chg, memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics. Incrementing
a semaphore requires release semantics. Trying to do both at once
in a single atomic operation requires acquire/release semantics.
I still need to port it to Relacy, but it seems like you need
acq_rel here.
Think about it... Waiting for something, implies acquire semantics.
No, when I release a lock and could have modified data,
I need release-semantics.
So, how can one utilize dual_monitor::wait? Does it wait on something?
Its like waiting on a condvar, which might have modified any data
before.
I was thinking along those lines. However, waiting on a condvar involves several steps. It also involves reacquiring the mutex...
Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
On 9/27/2021 11:34 PM, Bonita Montero wrote:
If the system hasn't any resources to satisfy a simple WaitForSingle...
spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full
speed!
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
On 28/09/2021 12:06, Bonita Montero wrote:
Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
On 9/27/2021 11:34 PM, Bonita Montero wrote:
If the system hasn't any resources to satisfy a simple WaitForSingle... >>>> spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full
speed!
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
Chris, why do you keep trying to communicate with Bonita? She is
clearly so convinced of her own superiority to everyone else that it is pointless. She does not post code for people to check, she posts it
because she thinks she is showing off and impressing people. This kind
of code is difficult to get right, and any capable developer is going to
want to discuss it with people to check the details. Since Bonita
responds with nothing but insults and arrogance, I think it is safe to
assume her code is flawed and leave her with it.
Am 28.09.2021 um 16:05 schrieb David Brown:
On 28/09/2021 12:06, Bonita Montero wrote:
Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
On 9/27/2021 11:34 PM, Bonita Montero wrote:
If the system hasn't any resources to satisfy a simple
WaitForSingle...
spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full
speed!
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
Chris, why do you keep trying to communicate with Bonita? She is
clearly so convinced of her own superiority to everyone else that it is
pointless. She does not post code for people to check, she posts it
because she thinks she is showing off and impressing people. This kind
of code is difficult to get right, and any capable developer is going to
want to discuss it with people to check the details. Since Bonita
responds with nothing but insults and arrogance, I think it is safe to
assume her code is flawed and leave her with it.
Chris doesn't understand my code. He even doesn't understand that before
any wait-operations you use atomic operations with release consistency
and after you use atomic operations with acquire-consistency. He is
totally confused.
And with the above code: once a visitor has incremented the visitor
-counter it can't decrement it because it might have decremented by
the code wanting to wake up a visitor. So under extreme conditions
where the system doesn't have the least resources to satisfy such a
simple operations spinning is quite o.k. until the conditions become
better. The system isn't usable anyway then.
It's simply frustrating to explain such simple things. Chris is simply
a n00b which lacks basic knowledge.
On 28/09/2021 12:06, Bonita Montero wrote:
Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
On 9/27/2021 11:34 PM, Bonita Montero wrote:
If the system hasn't any resources to satisfy a simple WaitForSingle... >>>> spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full
speed!
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
Chris, why do you keep trying to communicate with Bonita? She is
clearly so convinced of her own superiority to everyone else that it is pointless. She does not post code for people to check, she posts it
because she thinks she is showing off and impressing people. This kind
of code is difficult to get right, and any capable developer is going to
want to discuss it with people to check the details. Since Bonita
responds with nothing but insults and arrogance, I think it is safe to
assume her code is flawed and leave her with it.
working with it.
I wonder if she knows what a #LoadStore | #LoadLoad barrier is. That
MEMBAR instruction was fun on the SPARC. ;^)
On 9/28/2021 2:42 PM, Chris M. Thomasson wrote:
working with it.
I wonder if she knows what a #LoadStore | #LoadLoad barrier is. That
MEMBAR instruction was fun on the SPARC. ;^)
Not quite a membar, but on PowerPC, the EIEIO instruction was also fun.
On 9/27/2021 10:27 PM, Chris M. Thomasson wrote:semaphore wait then acquire
On 9/27/2021 9:55 PM, Bonita Montero wrote:
Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception >>>>>>> might
be thrown. These states are all true or false so I combined them to a >>>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>>> state isn't associated with an out of range condition. This helps me >>>>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the >>>>>>> code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>>>> memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics.
No, I could have modified data before, so I need, release-semantics.
You are such a n00b.
Waiting on something is acquire by nature. Show me where its not?
Actually, show me where to place the acquire and release barriers in a semaphore? Can you do it? Should be a piece of cake, right?
On 28/09/2021 12:06, Bonita Montero wrote:She is clever, but newb. Forgive her for that.
Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
On 9/27/2021 11:34 PM, Bonita Montero wrote:
If the system hasn't any resources to satisfy a simple WaitForSingle... >>>> spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full
speed!
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
Chris, why do you keep trying to communicate with Bonita? She is
clearly so convinced of her own superiority to everyone else that it is pointless. She does not post code for people to check, she posts it
because she thinks she is showing off and impressing people. This kind
of code is difficult to get right, and any capable developer is going to
want to discuss it with people to check the details. Since Bonita
responds with nothing but insults and arrogance, I think it is safe to
assume her code is flawed and leave her with it.
On 2021-09-28, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 9/27/2021 10:27 PM, Chris M. Thomasson wrote:semaphore wait then acquire
On 9/27/2021 9:55 PM, Bonita Montero wrote:
Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson:
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception >>>>>>>> might
be thrown. These states are all true or false so I combined them to a >>>>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>>>> state isn't associated with an out of range condition. This helps me >>>>>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the >>>>>>>> code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, chg,[...]
memory_order_release, memory_order_relaxed ) );
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics.
No, I could have modified data before, so I need, release-semantics.
You are such a n00b.
Waiting on something is acquire by nature. Show me where its not?
Actually, show me where to place the acquire and release barriers in a
semaphore? Can you do it? Should be a piece of cake, right?
On 9/28/2021 2:42 PM, Chris M. Thomasson wrote:
working with it.
I wonder if she knows what a #LoadStore | #LoadLoad barrier is. That
MEMBAR instruction was fun on the SPARC. ;^)
Not quite a membar, but on PowerPC, the EIEIO instruction was also fun.
Yeah. Damn. She does not seem to know a whole lot about memory barriers,
The most challenging architecture, AFAIK, was the Alpha.
Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson:
Yeah. Damn. She does not seem to know a whole lot about memory barriers,
I use them a lot and correctly.
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Am 29.09.2021 um 08:35 schrieb David Brown:
The most challenging architecture, AFAIK, was the Alpha.
The Alpha isn't challenging because it has the most relaxed memory
-ordering of all CPUs: If there would be a C++11-compiler for the
alpha you would use conventional membars and the code virtually
executes like on every other CPU.
On 2021-09-28, David Brown <david.brown@hesbynett.no> wrote:
On 28/09/2021 12:06, Bonita Montero wrote:She is clever, but newb. Forgive her for that.
Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
On 9/27/2021 11:34 PM, Bonita Montero wrote:
If the system hasn't any resources to satisfy a simple WaitForSingle... >>>>> spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full
speed!
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
Chris, why do you keep trying to communicate with Bonita? She is
clearly so convinced of her own superiority to everyone else that it is
pointless. She does not post code for people to check, she posts it
because she thinks she is showing off and impressing people. This kind
of code is difficult to get right, and any capable developer is going to
want to discuss it with people to check the details. Since Bonita
responds with nothing but insults and arrogance, I think it is safe to
assume her code is flawed and leave her with it.
Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson:
On 9/29/2021 3:41 AM, Bonita Montero wrote:
Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson:
Yeah. Damn. She does not seem to know a whole lot about memory
barriers,
I use them a lot and correctly.
A wait on a semaphore does not need release semantics. ...
It needs because I could have modiefied data before releasing the
lock I'm waiting for just at the same time.
On 9/29/2021 3:41 AM, Bonita Montero wrote:
Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson:
Yeah. Damn. She does not seem to know a whole lot about memory barriers,
I use them a lot and correctly.
A wait on a semaphore does not need release semantics. ...
Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson:
On 9/29/2021 3:41 AM, Bonita Montero wrote:
Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson:
Yeah. Damn. She does not seem to know a whole lot about memory
barriers,
I use them a lot and correctly.
A wait on a semaphore does not need release semantics. ...
It needs because I could have modiefied data before releasing the
lock I'm waiting for just at the same time.
Am 28.09.2021 um 09:03 schrieb Chris M. Thomasson:
On 9/27/2021 11:33 PM, Bonita Montero wrote:
Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson:
On 9/27/2021 9:57 PM, Bonita Montero wrote:
Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson:
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote:No, when I release a lock and could have modified data,
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an
exception might
be thrown. These states are all true or false so I combined >>>>>>>>>> them to a
four bit pattern wich I used as an index to a table which
stores the
strings of the out_of_range exception to be trown or a nullptr >>>>>>>>>> if the
state isn't associated with an out of range condition. This >>>>>>>>>> helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines >>>>>>>>>> around the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>>>> chg, memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released, >>>>>>>> so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics. Incrementing >>>>>>> a semaphore requires release semantics. Trying to do both at once >>>>>>> in a single atomic operation requires acquire/release semantics. >>>>>>>
I still need to port it to Relacy, but it seems like you need
acq_rel here.
Think about it... Waiting for something, implies acquire semantics. >>>>>
I need release-semantics.
So, how can one utilize dual_monitor::wait? Does it wait on something?
Its like waiting on a condvar, which might have modified any data
before.
I was thinking along those lines. However, waiting on a condvar
involves several steps. It also involves reacquiring the mutex...
With what I do the reacquisition is done by the side that unlocks the
mutex. It simply keeps the locked-flag while unlocking and sets the visitor-event.
Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson:
On 9/29/2021 3:41 AM, Bonita Montero wrote:
Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson:
Yeah. Damn. She does not seem to know a whole lot about memory
barriers,
I use them a lot and correctly.
A wait on a semaphore does not need release semantics. ...
It needs because I could have modiefied data before releasing the
lock I'm waiting for just at the same time.
On 9/28/2021 3:05 AM, Bonita Montero wrote:
Am 28.09.2021 um 09:03 schrieb Chris M. Thomasson:
On 9/27/2021 11:33 PM, Bonita Montero wrote:
Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson:
On 9/27/2021 9:57 PM, Bonita Montero wrote:Its like waiting on a condvar, which might have modified any data
Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson:
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote:No, when I release a lock and could have modified data,
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an
exception might
be thrown. These states are all true or false so I combined >>>>>>>>>>> them to a
four bit pattern wich I used as an index to a table which >>>>>>>>>>> stores the
strings of the out_of_range exception to be trown or a
nullptr if the
state isn't associated with an out of range condition. This >>>>>>>>>>> helps me
to prevent some if-else-cascades and speeds up the code. >>>>>>>>>>> So this is the complete function but i put two empty lines >>>>>>>>>>> around the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>>>>> chg, memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released, >>>>>>>>> so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics.
Incrementing a semaphore requires release semantics. Trying to >>>>>>>> do both at once in a single atomic operation requires
acquire/release semantics.
I still need to port it to Relacy, but it seems like you need
acq_rel here.
Think about it... Waiting for something, implies acquire semantics. >>>>>>
I need release-semantics.
So, how can one utilize dual_monitor::wait? Does it wait on something? >>>>
before.
I was thinking along those lines. However, waiting on a condvar
involves several steps. It also involves reacquiring the mutex...
With what I do the reacquisition is done by the side that unlocks the
mutex. It simply keeps the locked-flag while unlocking and sets the
visitor-event.
Where are your example use cases for dual_monitor? ...
Am 30.09.2021 um 06:57 schrieb Chris M. Thomasson:
On 9/28/2021 3:05 AM, Bonita Montero wrote:
Am 28.09.2021 um 09:03 schrieb Chris M. Thomasson:
On 9/27/2021 11:33 PM, Bonita Montero wrote:
Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson:
On 9/27/2021 9:57 PM, Bonita Montero wrote:
Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson:
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote:No, when I release a lock and could have modified data,
On 9/27/2021 5:44 AM, Bonita Montero wrote:
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:[...]
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an >>>>>>>>>>>> exception might
be thrown. These states are all true or false so I combined >>>>>>>>>>>> them to a
four bit pattern wich I used as an index to a table which >>>>>>>>>>>> stores the
strings of the out_of_range exception to be trown or a >>>>>>>>>>>> nullptr if the
state isn't associated with an out of range condition. This >>>>>>>>>>>> helps me
to prevent some if-else-cascades and speeds up the code. >>>>>>>>>>>> So this is the complete function but i put two empty lines >>>>>>>>>>>> around the
code I mentioned.
void dual_monitor::wait( bool b )
} while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>>>>>> chg, memory_order_release, memory_order_relaxed ) );[...]
Humm... For some reason I feel the need for
std::memory_order_acq_rel here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released, >>>>>>>>>> so it's release-consistency.
You always write nonsense.
Decrementing a semaphore requires acquire semantics.
Incrementing a semaphore requires release semantics. Trying to >>>>>>>>> do both at once in a single atomic operation requires
acquire/release semantics.
I still need to port it to Relacy, but it seems like you need >>>>>>>>> acq_rel here.
Think about it... Waiting for something, implies acquire semantics. >>>>>>>
I need release-semantics.
So, how can one utilize dual_monitor::wait? Does it wait on
something?
Its like waiting on a condvar, which might have modified any data
before.
I was thinking along those lines. However, waiting on a condvar
involves several steps. It also involves reacquiring the mutex...
With what I do the reacquisition is done by the side that unlocks the
mutex. It simply keeps the locked-flag while unlocking and sets the
visitor-event.
Where are your example use cases for dual_monitor? ...
It's usable when two threads communicate bidirectional.
On 9/28/2021 7:32 PM, Branimir Maksimovic wrote:
On 2021-09-28, David Brown <david.brown@hesbynett.no> wrote:
On 28/09/2021 12:06, Bonita Montero wrote:She is clever, but newb. Forgive her for that.
Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
On 9/27/2021 11:34 PM, Bonita Montero wrote:
If the system hasn't any resources to satisfy a simple WaitForSingle... >>>>>> spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full >>>>> speed!
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the
system when its in dire straights?
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
Chris, why do you keep trying to communicate with Bonita? She is
clearly so convinced of her own superiority to everyone else that it is
pointless. She does not post code for people to check, she posts it
because she thinks she is showing off and impressing people. This kind
of code is difficult to get right, and any capable developer is going to >>> want to discuss it with people to check the details. Since Bonita
responds with nothing but insults and arrogance, I think it is safe to
assume her code is flawed and leave her with it.
She is clever.
That's a bit vague. One can create highly efficient bidirectional communication between two threads using two wait-free single-producer/single-consumer queues without using any atomic RMW's,
just atomic loads, stores, and some some cleverly placed membars.
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it.
Sorry.
That's a bit vague. One can create highly efficient bidirectional
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic RMW's,
just atomic loads, stores, and some some cleverly placed membars.
When you use wait-free or lock-free algorithms and there's no data
you have to poll.
On 9/30/2021 3:39 AM, Bonita Montero wrote:
That's a bit vague. One can create highly efficient bidirectional
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed membars.
When you use wait-free or lock-free algorithms and there's no data
you have to poll.
Why?
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it.
Sorry.
In the mean time, I am working on another fractal set to music. Like
these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:
That's a bit vague. One can create highly efficient bidirectionalWhen you use wait-free or lock-free algorithms and there's no data
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed membars. >>
you have to poll.
Why?Because you don't have to wait in the kernel.
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:An error occurred. Please try again later. (Playback ID: pHR4vgIqqp13ECHz) Learn More
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it.
Sorry.
In the mean time, I am working on another fractal set to music. Like
these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Am 01.10.2021 um 13:43 schrieb Öö Tiib:Poof. you spin me around like a record? :P
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectionalWhen you use wait-free or lock-free algorithms and there's no data
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed membars. >>>>>
you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins. Lock-free and wait-free datastructures are idiocracy except
from lock-free stacks.
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectionalWhen you use wait-free or lock-free algorithms and there's no data
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed membars. >>>>
you have to poll.
Why?
What a thread does when its input queue is empty?
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:
That's a bit vague. One can create highly efficient bidirectionalWhen you use wait-free or lock-free algorithms and there's no data
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed membars. >>>
you have to poll.
Why?
Because you don't have to wait in the kernel.
On 2021-09-30, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:An error occurred. Please try again later. (Playback ID: pHR4vgIqqp13ECHz) Learn More
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>> be thrown. These states are all true or false so I combined them to a[...]
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it.
Sorry.
In the mean time, I am working on another fractal set to music. Like
these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed
membars.
When you use wait-free or lock-free algorithms and there's no data
you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins.
Lock-free and wait-free datastructures are idiocracy except
from lock-free stacks.
On Thu, 30 Sep 2021 13:00:53 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>> be thrown. These states are all true or false so I combined them to a[...]
four bit pattern wich I used as an index to a table which stores the
strings of the out_of_range exception to be trown or a nullptr if the
state isn't associated with an out of range condition. This helps me
to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the
code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it.
Sorry.
In the mean time, I am working on another fractal set to music. Like
these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Very impressive.
Could use maybe a few more colours though.
On 10/1/2021 6:07 AM, Branimir Maksimovic wrote:Safari, iCloud private relay.... ipv6
On 2021-09-30, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:An error occurred. Please try again later. (Playback ID: pHR4vgIqqp13ECHz) >> Learn More
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>>> be thrown. These states are all true or false so I combined them to a >>>>> four bit pattern wich I used as an index to a table which stores the >>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>> state isn't associated with an out of range condition. This helps me >>>>> to prevent some if-else-cascades and speeds up the code.[...]
So this is the complete function but i put two empty lines around the >>>>> code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it.
Sorry.
In the mean time, I am working on another fractal set to music. Like
these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
That's odd. The links I posted work for me. Just checked them. Humm...
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed
membars.
When you use wait-free or lock-free algorithms and there's no data
you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins. Lock-free and wait-free datastructures are idiocracy except
from lock-free stacks.
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>> communication between two threads using two wait-freeWhen you use wait-free or lock-free algorithms and there's no data you >>>>>> have to poll.
single-producer/single-consumer queues without using any atomic RMW's, >>>>>>> just atomic loads, stores, and some some cleverly placed membars. >>>>>>
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it spins.
Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack into account. When its empty we can use, say, a futex to wait on it. This would be the slow-path. A fast-path is when the stack is not empty. There is a big difference between a fast and a slow path. The former is lock-free, the latter might have to wait.
This even works for wait-free structures. In this case, the fast-path would be wait-free.
Heh, rsyncing something, looking bloat and have no patience :pLock-free and wait-free datastructures are idiocracy except from lock-free >> stacks.
Sure. Whatever you say Bonita. Cough.... Cough... ;^)
On Wed, 29 Sep 2021 12:05:24 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 9/28/2021 7:32 PM, Branimir Maksimovic wrote:
On 2021-09-28, David Brown <david.brown@hesbynett.no> wrote:
On 28/09/2021 12:06, Bonita Montero wrote:She is clever, but newb. Forgive her for that.
Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson:
On 9/27/2021 11:34 PM, Bonita Montero wrote:
If the system hasn't any resources to satisfy a simple WaitForSingle... >>>>>>> spinning is quite o.k..
spinning indeed. However, you have no backoff. You are spinning full >>>>>> speed!
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
Oh shit. When shit hits the fan, so does this! Try to not bleed the >>>>>> system when its in dire straights?
That doesnt't matter under such conditions.
Am I talking to a complete moron here ?
Chris, why do you keep trying to communicate with Bonita? She is
clearly so convinced of her own superiority to everyone else that it is >>>> pointless. She does not post code for people to check, she posts it
because she thinks she is showing off and impressing people. This kind >>>> of code is difficult to get right, and any capable developer is going to >>>> want to discuss it with people to check the details. Since Bonita
responds with nothing but insults and arrogance, I think it is safe to >>>> assume her code is flawed and leave her with it.
She is clever.
Clever in a small area. She seems to have limited knowledge of development and OS methodologies that arn't commonly used in Windows however.
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack >> into account. When its empty we can use, say, a futex to wait on it. This
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>> communication between two threads using two wait-freeWhen you use wait-free or lock-free algorithms and there's no data you >>>>>>> have to poll.
single-producer/single-consumer queues without using any atomic RMW's, >>>>>>>> just atomic loads, stores, and some some cleverly placed membars. >>>>>>>
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it spins. >>
would be the slow-path. A fast-path is when the stack is not empty. There is >> a big difference between a fast and a slow path. The former is lock-free, the
latter might have to wait.
This even works for wait-free structures. In this case, the fast-path would >> be wait-free.
Watch out that "wait free" isn't just spining with more cpomplex algorithm doing nothing usefull :P
here is mine mutex:
format elf64
FUTEX_WAIT equ 0
FUTEX_WAKE equ 1
FUTEX_PRIVATE_FLAG equ 128
public futex_acquire
public futex_release
futex_acquire:
push rbx
push r15
; push r10
mov r15,rdi
.L0:
mov ebx,1
xor eax,eax
lock cmpxchg [r15],ebx
test eax,eax
jz .L1
mov eax, 202
mov rdi, r15
mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
mov edx, 1
xor r10,r10
syscall
jmp .L0
.L1:; pop r10
pop r15
pop rbx
ret
futex_release:
lock and dword[rdi],0
mov eax,202
; mov rdi, sema
mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
mov edx,1
syscall
ret
Heh, rsyncing something, looking bloat and have no patience :p
Lock-free and wait-free datastructures are idiocracy except from lock-free >>> stacks.
Sure. Whatever you say Bonita. Cough.... Cough... ;^)
On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>>> communication between two threads using two wait-freeWhen you use wait-free or lock-free algorithms and there's no data you >>>>>>>> have to poll.
single-producer/single-consumer queues without using any atomic RMW's,
just atomic loads, stores, and some some cleverly placed membars. >>>>>>>>
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it spins. >>>
into account. When its empty we can use, say, a futex to wait on it. This >>> would be the slow-path. A fast-path is when the stack is not empty. There is
a big difference between a fast and a slow path. The former is lock-free, the
latter might have to wait.
This even works for wait-free structures. In this case, the fast-path would >>> be wait-free.
Watch out that "wait free" isn't just spining with more cpomplex algorithm >> doing nothing usefull :P
True! Imvvvho, wait-free should be loopless. Now, I always got nervous
over trying to implement wait-free with LL/SC, an optimistic atomic primitive. I prefer to implement them using pessimistic atomic ops like
an atomic exchange or fetch-and-add. However, then again atomic exchange
can be implemented by LL/SC, or CAS. This is not Kosher in my mind.
Quite fond of the pessimistic x86 XADD or XCHG atomic OPS when it comes
to wait-free because there is no looping involved. Actually, CAS in x86
can be used for a state machine without looping because it always
returns a result. If CAS on x86 fails we have the reason why. This is different than LL/SC that can spuriously fail.
here is mine mutex:
format elf64
FUTEX_WAIT equ 0
FUTEX_WAKE equ 1
FUTEX_PRIVATE_FLAG equ 128
public futex_acquire
public futex_release
futex_acquire:
push rbx
push r15
; push r10
mov r15,rdi
.L0:
mov ebx,1
xor eax,eax
lock cmpxchg [r15],ebx
test eax,eax
jz .L1
mov eax, 202
mov rdi, r15
mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
mov edx, 1
xor r10,r10
syscall
jmp .L0
.L1:; pop r10
pop r15
pop rbx
ret
futex_release:
lock and dword[rdi],0
mov eax,202
; mov rdi, sema
mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
mov edx,1
syscall
ret
Need to look at it, should work. Fwiw, here is an example using a futex
on windows. Yes it actually has one, lol! Btw, this is using XCHG only. ______________________________________
#include <iostream>
#include <thread>
#include <functional>
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#define CT_L2_ALIGNMENT 128
#define CT_THREADS 32
#define CT_ITERS 6666666
struct ct_futex_mutex
{
ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0)
{
}
void lock()
{
if (InterlockedExchange(&m_state, 1))
{
while (InterlockedExchange(&m_state, 2))
{
ULONG cmp = 2;
WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
}
}
}
void unlock()
{
if (InterlockedExchange(&m_state, 0) == 2)
{
WakeByAddressSingle(&m_state);
}
}
};
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:Same thing practically, except linux futex, which is same thing. Interrestingly Darwin does not have it and I am really interrested
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote: >>>>>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>>>> communication between two threads using two wait-freeWhen you use wait-free or lock-free algorithms and there's no data you
single-producer/single-consumer queues without using any atomic RMW's,
just atomic loads, stores, and some some cleverly placed membars. >>>>>>>>>
have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it spins.
Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack
into account. When its empty we can use, say, a futex to wait on it. This >>>> would be the slow-path. A fast-path is when the stack is not empty. There is
a big difference between a fast and a slow path. The former is lock-free, the
latter might have to wait.
This even works for wait-free structures. In this case, the fast-path would
be wait-free.
Watch out that "wait free" isn't just spining with more cpomplex algorithm >>> doing nothing usefull :P
True! Imvvvho, wait-free should be loopless. Now, I always got nervous
over trying to implement wait-free with LL/SC, an optimistic atomic
primitive. I prefer to implement them using pessimistic atomic ops like
an atomic exchange or fetch-and-add. However, then again atomic exchange
can be implemented by LL/SC, or CAS. This is not Kosher in my mind.
Quite fond of the pessimistic x86 XADD or XCHG atomic OPS when it comes
to wait-free because there is no looping involved. Actually, CAS in x86
can be used for a state machine without looping because it always
returns a result. If CAS on x86 fails we have the reason why. This is
different than LL/SC that can spuriously fail.
here is mine mutex:
format elf64
FUTEX_WAIT equ 0
FUTEX_WAKE equ 1
FUTEX_PRIVATE_FLAG equ 128
public futex_acquire
public futex_release
futex_acquire:
push rbx
push r15
; push r10
mov r15,rdi
.L0:
mov ebx,1
xor eax,eax
lock cmpxchg [r15],ebx
test eax,eax
jz .L1
mov eax, 202
mov rdi, r15
mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
mov edx, 1
xor r10,r10
syscall
jmp .L0
.L1:; pop r10
pop r15
pop rbx
ret
futex_release:
lock and dword[rdi],0
mov eax,202
; mov rdi, sema
mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
mov edx,1
syscall
ret
Need to look at it, should work. Fwiw, here is an example using a futex
on windows. Yes it actually has one, lol! Btw, this is using XCHG only. >> ______________________________________
#include <iostream>
#include <thread>
#include <functional>
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#define CT_L2_ALIGNMENT 128
#define CT_THREADS 32
#define CT_ITERS 6666666
struct ct_futex_mutex
{
ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0)
{
}
void lock()
{
if (InterlockedExchange(&m_state, 1))
{
while (InterlockedExchange(&m_state, 2))
{
ULONG cmp = 2;
WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
}
}
}
void unlock()
{
if (InterlockedExchange(&m_state, 0) == 2)
{
WakeByAddressSingle(&m_state);
}
}
};
how Apple immplements pthread_mutex?
On 10/1/2021 3:13 PM, Branimir Maksimovic wrote:
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: [...]
There is another way to create a nice FIFO mutex
using a fast semaphore. Iirc, it was called a benaphore:
https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
On 30/09/2021 03:33, Bonita Montero wrote:
Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson:
On 9/29/2021 3:41 AM, Bonita Montero wrote:
Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson:
Yeah. Damn. She does not seem to know a whole lot about memory
barriers,
I use them a lot and correctly.
A wait on a semaphore does not need release semantics. ...
It needs because I could have modiefied data before releasing the
lock I'm waiting for just at the same time.
If you release a lock, you need release semantics. If you acquire a
lock, you need acquire semantics.
There is a lot of fiddly stuff in getting memory barriers and
synchronisation right - and a lot of /really/ tough stuff in getting it
right and optimally efficient on big processors. But "acquire" and
"release" semantics are helpfully named!
On 9/30/2021 12:10 AM, David Brown wrote:
On 30/09/2021 03:33, Bonita Montero wrote:
Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson:
On 9/29/2021 3:41 AM, Bonita Montero wrote:
Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson:
Yeah. Damn. She does not seem to know a whole lot about memory
barriers,
I use them a lot and correctly.
A wait on a semaphore does not need release semantics. ...
It needs because I could have modiefied data before releasing the
lock I'm waiting for just at the same time.
If you release a lock, you need release semantics. If you acquire a
lock, you need acquire semantics.
There is a lot of fiddly stuff in getting memory barriers and
synchronisation right - and a lot of /really/ tough stuff in getting it
right and optimally efficient on big processors. But "acquire" and
"release" semantics are helpfully named!
They are named nicely. Back on the SPARC acquire is:
MEMBAR #LoadStore | #LoadLoad
Release is:
MEMBAR #LoadStore | #StoreStore
Ahhh, then we have hardcore: #StoreLoad. SMR required this on the SPARC.
Problem is that Apple act like student newbs. They don't care aboutSame thing practically, except linux futex, which is same thing.FUTEX_WAKE equ 1
Interrestingly Darwin does not have it and I am really interrested
how Apple immplements pthread_mutex?
Ohhhh... Good question. I am not sure about Darwin. Actually, there is a
way to implement the mutex I showed you using binary semaphores for the
slow path. Iirc, it went like this, with the futex part commented out,
and the initialization of the binary sema to zero, auto-reset event on windoze, also out:
____________________________yeah...
struct ct_futex_mutex
{
ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0)
{
}
void lock()
{
if (InterlockedExchange(&m_state, 1))
{
while (InterlockedExchange(&m_state, 2))
{
//ULONG cmp = 2;
//WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
WaitForSingleObject(m_event, INFINITE);
}
}
}
void unlock()
{
if (InterlockedExchange(&m_state, 0) == 2)
{
//WakeByAddressSingle(&m_state);
SetEvent(m_event);
}
}
};
____________________________
That works as well. Humm...
https://github.com/apple/darwin-libpthread/blob/main/man/pthread_mutex_lock.3I look...
https://github.com/apple/darwin-libpthread/blob/main/src/pthread_mutex.c
Need to example this! There is another way to create a nice FIFO mutex
using a fast semaphore. Iirc, it was called a benaphore:
https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
On 10/1/2021 3:13 PM, Branimir Maksimovic wrote:Here is Apple version:
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:Same thing practically, except linux futex, which is same thing.
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote: >>>>>>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly placed >>>>>>>>>>> membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it >>>>>> spins.
Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic >>>>> stack into account. When its empty we can use, say, a futex to wait on >>>>> it. This would be the slow-path. A fast-path is when the stack is not >>>>> empty. There is a big difference between a fast and a slow path. The >>>>> former is lock-free, the latter might have to wait.
This even works for wait-free structures. In this case, the fast-path >>>>> would be wait-free.
Watch out that "wait free" isn't just spining with more cpomplex algorithm >>>> doing nothing usefull :P
True! Imvvvho, wait-free should be loopless. Now, I always got nervous over >>> trying to implement wait-free with LL/SC, an optimistic atomic primitive. I >>> prefer to implement them using pessimistic atomic ops like an atomic
exchange or fetch-and-add. However, then again atomic exchange can be
implemented by LL/SC, or CAS. This is not Kosher in my mind. Quite fond of >>> the pessimistic x86 XADD or XCHG atomic OPS when it comes to wait-free
because there is no looping involved. Actually, CAS in x86 can be used for >>> a state machine without looping because it always returns a result. If CAS >>> on x86 fails we have the reason why. This is different than LL/SC that can >>> spuriously fail.
here is mine mutex: format elf64
FUTEX_WAIT equ 0 FUTEX_WAKE equ 1
FUTEX_PRIVATE_FLAG equ 128
public futex_acquire public futex_release
futex_acquire: push rbx push r15 ; push r10 mov r15,rdi .L0: mov ebx,1 xor >>>> eax,eax lock cmpxchg [r15],ebx test eax,eax jz .L1 mov eax, 202 mov rdi, >>>> r15 mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG mov edx, 1 xor r10,r10
syscall jmp .L0 .L1:; pop r10 pop r15 pop rbx ret
futex_release: lock and dword[rdi],0 mov eax,202 ; mov rdi, sema >>>> mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG mov edx,1 syscall ret
Need to look at it, should work. Fwiw, here is an example using a futex on >>> windows. Yes it actually has one, lol! Btw, this is using XCHG only.
______________________________________ #include <iostream> #include
<thread> #include <functional>
#define WIN32_LEAN_AND_MEAN #include <Windows.h>
#define CT_L2_ALIGNMENT 128 #define CT_THREADS 32 #define CT_ITERS 6666666 >>>
struct ct_futex_mutex { ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0) {
}
void lock() { if (InterlockedExchange(&m_state, 1)) { while
(InterlockedExchange(&m_state, 2)) { ULONG cmp = 2;
WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE); } } }
void unlock() { if (InterlockedExchange(&m_state, 0) == 2) {
WakeByAddressSingle(&m_state); } } };
Interrestingly Darwin does not have it and I am really interrested how Apple >> immplements pthread_mutex?
Ohhhh... Good question. I am not sure about Darwin. Actually, there is a way to implement the mutex I showed you using binary semaphores for the slow path. Iirc, it went like this, with the futex part commented out, and the initialization of the binary sema to zero, auto-reset event on windoze, also out: ____________________________ struct ct_futex_mutex { ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0) {
}
void lock() { if (InterlockedExchange(&m_state, 1)) { while
(InterlockedExchange(&m_state, 2)) { //ULONG cmp = 2;
//WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
WaitForSingleObject(m_event, INFINITE); } } }
void unlock() { if (InterlockedExchange(&m_state, 0) == 2) {
//WakeByAddressSingle(&m_state);
SetEvent(m_event); } } }; ____________________________
That works as well. Humm...
https://github.com/apple/darwin-libpthread/blob/main/man/pthread_mutex_lock.3
https://github.com/apple/darwin-libpthread/blob/main/src/pthread_mutex.c
Need to example this! There is another way to create a nice FIFO mutex using a fast semaphore. Iirc, it was called a benaphore:
https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
Heh, rsyncing something, looking bloat and have no patience :p
Lock-free and wait-free datastructures are idiocracy except from lock-free >>> stacks.
Sure. Whatever you say Bonita. Cough.... Cough... ;^)
On 2021-10-02, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:[...]
On 10/1/2021 3:13 PM, Branimir Maksimovic wrote:Here is Apple version:
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:
Same thing practically, except linux futex, which is same thing.On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>>> On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote: >>>>>>>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly placed >>>>>>>>>>>> membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>>>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it >>>>>>> spins.
Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic >>>>>> stack into account. When its empty we can use, say, a futex to wait on >>>>>> it. This would be the slow-path. A fast-path is when the stack is not >>>>>> empty. There is a big difference between a fast and a slow path. The >>>>>> former is lock-free, the latter might have to wait.
This even works for wait-free structures. In this case, the fast-path >>>>>> would be wait-free.
Watch out that "wait free" isn't just spining with more cpomplex algorithm
doing nothing usefull :P
True! Imvvvho, wait-free should be loopless. Now, I always got nervous over
trying to implement wait-free with LL/SC, an optimistic atomic primitive. I
prefer to implement them using pessimistic atomic ops like an atomic
exchange or fetch-and-add. However, then again atomic exchange can be
implemented by LL/SC, or CAS. This is not Kosher in my mind. Quite fond of
the pessimistic x86 XADD or XCHG atomic OPS when it comes to wait-free >>>> because there is no looping involved. Actually, CAS in x86 can be used for >>>> a state machine without looping because it always returns a result. If CAS >>>> on x86 fails we have the reason why. This is different than LL/SC that can >>>> spuriously fail.
here is mine mutex: format elf64
FUTEX_WAIT equ 0 FUTEX_WAKE equ 1
FUTEX_PRIVATE_FLAG equ 128
public futex_acquire public futex_release
futex_acquire: push rbx push r15 ; push r10 mov r15,rdi .L0: mov ebx,1 xor
eax,eax lock cmpxchg [r15],ebx test eax,eax jz .L1 mov eax, 202 mov rdi, >>>>> r15 mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG mov edx, 1 xor r10,r10 >>>>> syscall jmp .L0 .L1:; pop r10 pop r15 pop rbx ret
futex_release: lock and dword[rdi],0 mov eax,202 ; mov rdi, sema >>>>> mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG mov edx,1 syscall ret
Need to look at it, should work. Fwiw, here is an example using a futex on >>>> windows. Yes it actually has one, lol! Btw, this is using XCHG only.
______________________________________ #include <iostream> #include
<thread> #include <functional>
#define WIN32_LEAN_AND_MEAN #include <Windows.h>
#define CT_L2_ALIGNMENT 128 #define CT_THREADS 32 #define CT_ITERS 6666666 >>>>
struct ct_futex_mutex { ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0) {
}
void lock() { if (InterlockedExchange(&m_state, 1)) { while
(InterlockedExchange(&m_state, 2)) { ULONG cmp = 2;
WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE); } } }
void unlock() { if (InterlockedExchange(&m_state, 0) == 2) {
WakeByAddressSingle(&m_state); } } };
Interrestingly Darwin does not have it and I am really interrested how Apple
immplements pthread_mutex?
Ohhhh... Good question. I am not sure about Darwin. Actually, there is a way >> to implement the mutex I showed you using binary semaphores for the slow
path. Iirc, it went like this, with the futex part commented out, and the
initialization of the binary sema to zero, auto-reset event on windoze, also >> out: ____________________________ struct ct_futex_mutex { ULONG
alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0) {
}
void lock() { if (InterlockedExchange(&m_state, 1)) { while
(InterlockedExchange(&m_state, 2)) { //ULONG cmp = 2;
//WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
WaitForSingleObject(m_event, INFINITE); } } }
void unlock() { if (InterlockedExchange(&m_state, 0) == 2) {
//WakeByAddressSingle(&m_state);
SetEvent(m_event); } } }; ____________________________
That works as well. Humm...
https://github.com/apple/darwin-libpthread/blob/main/man/pthread_mutex_lock.3
https://github.com/apple/darwin-libpthread/blob/main/src/pthread_mutex.c
Need to example this! There is another way to create a nice FIFO mutex using >> a fast semaphore. Iirc, it was called a benaphore:
https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
Am 01.10.2021 um 22:04 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>> RMW's, just atomic loads, stores, and some some cleverly placed >>>>>>>> membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins.
Huh? Ever heard of a futex, or an eventcount?
Lock-free is without any kernel-structures and polling only.
No futex.
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed
membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins. Lock-free and wait-free datastructures are idiocracy except
from lock-free stacks.
So a lock-free stack is okay with you, but not a lock-free queue? Why?
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed
membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins.
Huh? Ever heard of a futex, or an eventcount?
Am 01.10.2021 um 22:20 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>> RMW's, just atomic loads, stores, and some some cleverly placed >>>>>>>> membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins. Lock-free and wait-free datastructures are idiocracy except
from lock-free stacks.
So a lock-free stack is okay with you, but not a lock-free queue? Why?
Because the use-cases of lock-free stacks are so that the
lock-free stacks are never polled.
On 10/1/2021 9:39 PM, Bonita Montero wrote:
Am 01.10.2021 um 22:04 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly placed >>>>>>>>> membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins.
Huh? Ever heard of a futex, or an eventcount?
Lock-free is without any kernel-structures and polling only.
No futex.
Lock-free on the fast-path... Ever heard of such a thing? Wow.
On 10/1/2021 9:40 PM, Bonita Montero wrote:
Am 01.10.2021 um 22:20 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly placed >>>>>>>>> membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins. Lock-free and wait-free datastructures are idiocracy except
from lock-free stacks.
So a lock-free stack is okay with you, but not a lock-free queue? Why?
Because the use-cases of lock-free stacks are so that the
lock-free stacks are never polled.
Never polled? A slow-path on a lock-free stack can be waited on.
Am 02.10.2021 um 07:12 schrieb Chris M. Thomasson:
On 10/1/2021 9:39 PM, Bonita Montero wrote:
Am 01.10.2021 um 22:04 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote: >>>>>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly
placed membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins.
Huh? Ever heard of a futex, or an eventcount?
Lock-free is without any kernel-structures and polling only.
No futex.
Lock-free on the fast-path... Ever heard of such a thing? Wow.
There is no slow path with lock-free structures.
On 10/1/2021 10:36 PM, Bonita Montero wrote:
Am 02.10.2021 um 07:14 schrieb Chris M. Thomasson:
On 10/1/2021 9:40 PM, Bonita Montero wrote:
Am 01.10.2021 um 22:20 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:Because the use-cases of lock-free stacks are so that the
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote: >>>>>>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient
bidirectional
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly >>>>>>>>>>> placed membars.
When you use wait-free or lock-free algorithms and there's no >>>>>>>>>> data
you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it >>>>>> spins. Lock-free and wait-free datastructures are idiocracy except >>>>>> from lock-free stacks.
So a lock-free stack is okay with you, but not a lock-free queue? Why? >>>>
lock-free stacks are never polled.
Never polled? A slow-path on a lock-free stack can be waited on.
Then it isn't lock-free.
I think I'm talking to a complete moron here.
Fast-path lock/wait-free, slow-path might have to hit the kernel to wait
on certain conditions. You seem to have never differentiated between the
two possible paths?
Am 02.10.2021 um 07:49 schrieb Chris M. Thomasson:
On 10/1/2021 10:35 PM, Bonita Montero wrote:
Am 02.10.2021 um 07:12 schrieb Chris M. Thomasson:
On 10/1/2021 9:39 PM, Bonita Montero wrote:
Am 01.10.2021 um 22:04 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote: >>>>>>>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient
bidirectional
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly >>>>>>>>>>>> placed membars.
When you use wait-free or lock-free algorithms and there's no >>>>>>>>>>> data
you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it >>>>>>> spins.
Huh? Ever heard of a futex, or an eventcount?
Lock-free is without any kernel-structures and polling only.
No futex.
Lock-free on the fast-path... Ever heard of such a thing? Wow.
There is no slow path with lock-free structures.
Ummmm... You are just trolling me right? A slow path would be what to
do when one needs to wait, on say, an empty condition? Humm... Why do
you troll?
Lock-free is when there's no kernel-locking involved.
And a slow-path involves kernel-locking.
Am 02.10.2021 um 07:55 schrieb Chris M. Thomasson:
On 10/1/2021 10:36 PM, Bonita Montero wrote:
Am 02.10.2021 um 07:14 schrieb Chris M. Thomasson:
On 10/1/2021 9:40 PM, Bonita Montero wrote:
Am 01.10.2021 um 22:20 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote: >>>>>>>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient
bidirectional
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly >>>>>>>>>>>> placed membars.
When you use wait-free or lock-free algorithms and there's no >>>>>>>>>>> data
you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it >>>>>>> spins. Lock-free and wait-free datastructures are idiocracy except >>>>>>> from lock-free stacks.
So a lock-free stack is okay with you, but not a lock-free queue?
Why?
Because the use-cases of lock-free stacks are so that the
lock-free stacks are never polled.
Never polled? A slow-path on a lock-free stack can be waited on.
Then it isn't lock-free.
I think I'm talking to a complete moron here.
Fast-path lock/wait-free, slow-path might have to hit the kernel to
wait on certain conditions. You seem to have never differentiated
between the two possible paths?
Lock-free is when there's no kernel-locking involved.
And a slow-path involves kernel-locking.
Am 02.10.2021 um 07:14 schrieb Chris M. Thomasson:
On 10/1/2021 9:40 PM, Bonita Montero wrote:
Am 01.10.2021 um 22:20 schrieb Chris M. Thomasson:
On 10/1/2021 5:59 AM, Bonita Montero wrote:
Am 01.10.2021 um 13:43 schrieb Öö Tiib:
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero wrote: >>>>>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
On 9/30/2021 3:39 AM, Bonita Montero wrote:Because you don't have to wait in the kernel.
That's a bit vague. One can create highly efficient bidirectional >>>>>>>>>> communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic >>>>>>>>>> RMW's, just atomic loads, stores, and some some cleverly
placed membars.
When you use wait-free or lock-free algorithms and there's no data >>>>>>>>> you have to poll.
Why?
What a thread does when its input queue is empty?
If it hasn't anything other to do than "waiting" for a new entry it
spins. Lock-free and wait-free datastructures are idiocracy except
from lock-free stacks.
So a lock-free stack is okay with you, but not a lock-free queue? Why?
Because the use-cases of lock-free stacks are so that the
lock-free stacks are never polled.
Never polled? A slow-path on a lock-free stack can be waited on.
Then it isn't lock-free.
I think I'm talking to a complete moron here.
Am 02.10.2021 um 08:12 schrieb Chris M. Thomasson:
Lock-free is when there's no kernel-locking involved.
A fast-path can be 100% pure lock/wait-free, so yes; indeed.
A slow-path can involve kernel locking. Are you late to the game?
And if you have kernel-locking you don't have any lock-free algorithm.
Lock-free is when there's no kernel-locking involved.
A fast-path can be 100% pure lock/wait-free, so yes; indeed.
A slow-path can involve kernel locking. Are you late to the game?
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can be
used to help it out. You know, if it must wait on an empty condition,
well, it can without spinning around. If the queue/stack is empty, we
can wait! Or not. Up to the programmer.
If you have a slow path you don't have a lock-free algorithm.
Why not? The slow-path can be avoided, from time to time. ...
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can be
used to help it out. You know, if it must wait on an empty condition,
well, it can without spinning around. If the queue/stack is empty, we
can wait! Or not. Up to the programmer.
If you have a slow path you don't have a lock-free algorithm.
Why not? The slow-path can be avoided, from time to time. Ever heard
about doing something else, instead of waiting in kernel land? I have
some older code that can show this. Its the type of thinking were...
Well, why should I wait when I can do something else. Actually, it works.
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can be used
to help it out. You know, if it must wait on an empty condition, well,
it can without spinning around. If the queue/stack is empty, we can
wait! Or not. Up to the programmer.
If you have a slow path you don't have a lock-free algorithm.
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:12 schrieb Chris M. Thomasson:
Lock-free is when there's no kernel-locking involved.
A fast-path can be 100% pure lock/wait-free, so yes; indeed.
A slow-path can involve kernel locking. Are you late to the game?
And if you have kernel-locking you don't have any lock-free algorithm.
WRONG! Think of the difference between a fast-path and a slow-path. The programmer can decide what to do.
Am 02.10.2021 um 08:39 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:12 schrieb Chris M. Thomasson:
Lock-free is when there's no kernel-locking involved.
A fast-path can be 100% pure lock/wait-free, so yes; indeed.
A slow-path can involve kernel locking. Are you late to the game?
And if you have kernel-locking you don't have any lock-free algorithm.
WRONG! Think of the difference between a fast-path and a slow-path.
The programmer can decide what to do.
No, not wrong. Lock-free is always without waiting in the kernel,
i.e. no locking.
Am 02.10.2021 um 08:41 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can be
used to help it out. You know, if it must wait on an empty
condition, well, it can without spinning around. If the queue/stack
is empty, we can wait! Or not. Up to the programmer.
If you have a slow path you don't have a lock-free algorithm.
Why not? The slow-path can be avoided, from time to time. ...
Lock-free is without locking all the time.
On 10/1/2021 11:47 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:41 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can be
used to help it out. You know, if it must wait on an empty
condition, well, it can without spinning around. If the queue/stack
is empty, we can wait! Or not. Up to the programmer.
If you have a slow path you don't have a lock-free algorithm.
Why not? The slow-path can be avoided, from time to time. ...
Lock-free is without locking all the time.
Think of fast path vs slow path. You have a lot to learn!
On 10/1/2021 11:46 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:39 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:12 schrieb Chris M. Thomasson:
Lock-free is when there's no kernel-locking involved.
A fast-path can be 100% pure lock/wait-free, so yes; indeed.
A slow-path can involve kernel locking. Are you late to the game?
And if you have kernel-locking you don't have any lock-free algorithm.
WRONG! Think of the difference between a fast-path and a slow-path.
The programmer can decide what to do.
No, not wrong. Lock-free is always without waiting in the kernel,
i.e. no locking.
You seem to really love the fast-path. So do I!!!! 100% pure
lock/wait-free depending on the algorihtm we are targeting.
However, we can wait on slow paths.
Am 02.10.2021 um 08:50 schrieb Chris M. Thomasson:
On 10/1/2021 11:46 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:39 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:12 schrieb Chris M. Thomasson:WRONG! Think of the difference between a fast-path and a slow-path.
And if you have kernel-locking you don't have any lock-free algorithm. >>>>Lock-free is when there's no kernel-locking involved.
A fast-path can be 100% pure lock/wait-free, so yes; indeed.
A slow-path can involve kernel locking. Are you late to the game? >>>>>
The programmer can decide what to do.
No, not wrong. Lock-free is always without waiting in the kernel,
i.e. no locking.
You seem to really love the fast-path. So do I!!!! 100% pure
lock/wait-free depending on the algorihtm we are targeting.
However, we can wait on slow paths.
Lock-free algorithms are _always_ non-blocking,
so there is never any slow path.
Am 02.10.2021 um 08:51 schrieb Chris M. Thomasson:
On 10/1/2021 11:47 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:41 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can be
used to help it out. You know, if it must wait on an empty
condition, well, it can without spinning around. If the
queue/stack is empty, we can wait! Or not. Up to the programmer.
If you have a slow path you don't have a lock-free algorithm.
Why not? The slow-path can be avoided, from time to time. ...
Lock-free is without locking all the time.
Think of fast path vs slow path. You have a lot to learn!
I know the difference. But lock-free algorithms are
_always_ non-blocking and _never_ have a slow path.
On 10/1/2021 11:53 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:51 schrieb Chris M. Thomasson:
On 10/1/2021 11:47 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:41 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can be >>>>>>> used to help it out. You know, if it must wait on an empty
condition, well, it can without spinning around. If the
queue/stack is empty, we can wait! Or not. Up to the programmer.
If you have a slow path you don't have a lock-free algorithm.
Why not? The slow-path can be avoided, from time to time. ...
Lock-free is without locking all the time.
Think of fast path vs slow path. You have a lot to learn!
I know the difference. But lock-free algorithms are
_always_ non-blocking and _never_ have a slow path.
ARGH! You are a pain to talk to. There is a way to use this even in
mutex logic. The slow path of a mutex is when its locked, and we have a
choice to wait, or perhaps try to do something else... Think about it!
On 10/1/2021 11:52 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:50 schrieb Chris M. Thomasson:
On 10/1/2021 11:46 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:39 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:12 schrieb Chris M. Thomasson:
And if you have kernel-locking you don't have any lock-freeLock-free is when there's no kernel-locking involved.
A fast-path can be 100% pure lock/wait-free, so yes; indeed.
A slow-path can involve kernel locking. Are you late to the game? >>>>>>
algorithm.
WRONG! Think of the difference between a fast-path and a slow-path.
The programmer can decide what to do.
No, not wrong. Lock-free is always without waiting in the kernel,
i.e. no locking.
You seem to really love the fast-path. So do I!!!! 100% pure
lock/wait-free depending on the algorihtm we are targeting.
However, we can wait on slow paths.
Lock-free algorithms are _always_ non-blocking,
so there is never any slow path.
Have you experienced something that required you to wait on certain conditions? Call the wait path a slow-path. Make the fast-paths as
fast as possible. Humm... Are you green?
Am 02.10.2021 um 09:01 schrieb Chris M. Thomasson:
On 10/1/2021 11:52 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:50 schrieb Chris M. Thomasson:
On 10/1/2021 11:46 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:39 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:12 schrieb Chris M. Thomasson:
And if you have kernel-locking you don't have any lock-freeLock-free is when there's no kernel-locking involved.
A fast-path can be 100% pure lock/wait-free, so yes; indeed.
A slow-path can involve kernel locking. Are you late to the game? >>>>>>>
algorithm.
WRONG! Think of the difference between a fast-path and a
slow-path. The programmer can decide what to do.
No, not wrong. Lock-free is always without waiting in the kernel,
i.e. no locking.
You seem to really love the fast-path. So do I!!!! 100% pure
lock/wait-free depending on the algorihtm we are targeting.
However, we can wait on slow paths.
Lock-free algorithms are _always_ non-blocking,
so there is never any slow path.
Have you experienced something that required you to wait on certain
conditions? Call the wait path a slow-path. Make the fast-paths as
fast as possible. Humm... Are you green?
There is no slow path with lock-free algorithms.
A mutex isn't a lock-free structure because is _also_ has a
slow path.
It can have a very nice fast-path... Have you ever created one?
A mutex isn't a lock-free structure because is _also_ has a
slow path.
Have you ever experimented with trying to do something else instead of waiting on a mutex?
On 2021-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:If you don't spin it is not lock :P
On 9/30/2021 3:39 AM, Bonita Montero wrote:
That's a bit vague. One can create highly efficient bidirectionalWhen you use wait-free or lock-free algorithms and there's no data
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed membars. >>>>
you have to poll.
Why?
Because you don't have to wait in the kernel.
problem is that only way you don't synchronize
is when things are *independent* from each other :P
Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson:
A mutex isn't a lock-free structure because is _also_ has a
slow path.
It can have a very nice fast-path... Have you ever created one?
That's not what we're talking about.
On 10/1/2021 6:08 AM, Branimir Maksimovic wrote:
On 2021-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:If you don't spin it is not lock :P
On 9/30/2021 3:39 AM, Bonita Montero wrote:
That's a bit vague. One can create highly efficient bidirectional
communication between two threads using two wait-free
single-producer/single-consumer queues without using any atomic
RMW's, just atomic loads, stores, and some some cleverly placed
membars.
When you use wait-free or lock-free algorithms and there's no data
you have to poll.
Why?
Because you don't have to wait in the kernel.
True. Hitting the fast path is very nice indeed!
problem is that only way you don't synchronize
is when things are *independent* from each other :P
Well, sometimes one can do other things instead of spinning/waiting,
even in a mutex locked condition. Its an interesting simple logic loop.
You have probably seen it before.
Am 02.10.2021 um 09:04 schrieb Chris M. Thomasson:
On 10/1/2021 11:53 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:51 schrieb Chris M. Thomasson:
On 10/1/2021 11:47 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:41 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can >>>>>>>> be used to help it out. You know, if it must wait on an emptyIf you have a slow path you don't have a lock-free algorithm.
condition, well, it can without spinning around. If the
queue/stack is empty, we can wait! Or not. Up to the programmer. >>>>>>>
Why not? The slow-path can be avoided, from time to time. ...
Lock-free is without locking all the time.
Think of fast path vs slow path. You have a lot to learn!
I know the difference. But lock-free algorithms are
_always_ non-blocking and _never_ have a slow path.
ARGH! You are a pain to talk to. There is a way to use this even in
mutex logic. The slow path of a mutex is when its locked, and we have
a choice to wait, or perhaps try to do something else... Think
about it!
A mutex isn't a lock-free structure because is _also_ has a
slow path.
Am 02.10.2021 um 09:04 schrieb Chris M. Thomasson:
On 10/1/2021 11:53 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:51 schrieb Chris M. Thomasson:
On 10/1/2021 11:47 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:41 schrieb Chris M. Thomasson:
On 10/1/2021 11:38 PM, Bonita Montero wrote:
Am 02.10.2021 um 08:08 schrieb Chris M. Thomasson:
One cal use lock-free in user-space! A futex or eventcount can >>>>>>>> be used to help it out. You know, if it must wait on an emptyIf you have a slow path you don't have a lock-free algorithm.
condition, well, it can without spinning around. If the
queue/stack is empty, we can wait! Or not. Up to the programmer. >>>>>>>
Why not? The slow-path can be avoided, from time to time. ...
Lock-free is without locking all the time.
Think of fast path vs slow path. You have a lot to learn!
I know the difference. But lock-free algorithms are
_always_ non-blocking and _never_ have a slow path.
ARGH! You are a pain to talk to. There is a way to use this even in
mutex logic. The slow path of a mutex is when its locked, and we have
a choice to wait, or perhaps try to do something else... Think
about it!
A mutex isn't a lock-free structure because is _also_ has a
slow path.
On 10/2/2021 12:31 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:24 schrieb Chris M. Thomasson:
A mutex isn't a lock-free structure because is _also_ has a
slow path.
Have you ever experimented with trying to do something else instead
of waiting on a mutex?
That's not what we're talking about.
Lock-free is when there is never any waiting in the kernel.
Lock-free is when its lock-free. Ugh!
Why do you make me want to cough when I read some of your comments? The
idea is to try to minimize slow-paths... Think about it! Damn it... ;^o
So lock/wait free algorithms are of great use! Not, what did you say, idiotic? Wow.
Am 02.10.2021 um 09:32 schrieb Chris M. Thomasson:
On 10/2/2021 12:31 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:24 schrieb Chris M. Thomasson:
A mutex isn't a lock-free structure because is _also_ has a
slow path.
Have you ever experimented with trying to do something else instead
of waiting on a mutex?
That's not what we're talking about.
Lock-free is when there is never any waiting in the kernel.
Lock-free is when its lock-free. Ugh!
Lock-free is when you only have a fast path - and no slow path.
Am 02.10.2021 um 09:26 schrieb Chris M. Thomasson:
There is no slow path with lock-free algorithms.
What about a stack-empty condition? ...
Lock-free stacks are used for pooling or handling back resoruces to an
owning thread.
In the first case the thread not finding any preallocated
items on the stack allocates them conventionally - and that has nothing
to do with locking - and in the latter case if the thread given back the resources doesn't find something on the stack it simply doesn't empty
the stack. If he would find sth. on the stack it would empty it and
put back the resoruces in its local pools.
So there's nothing wigh locking in either case.
I'm talking to a complete moron here.
There is no slow path with lock-free algorithms.
What about a stack-empty condition? ...
Lock-free stacks are used for pooling or handling back resoruces to an
owning thread.
Really, is that their only use? ..
Am 02.10.2021 um 12:03 schrieb Chris M. Thomasson:
Lock-free stacks are used for pooling or handling back resoruces to an
owning thread.
Really, is that their only use? ..
Yes.
On 10/1/2021 2:17 AM, RadicalRabbit@theburrow.co.uk wrote:
On Thu, 30 Sep 2021 13:00:53 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>>> be thrown. These states are all true or false so I combined them to a >>>>> four bit pattern wich I used as an index to a table which stores the >>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>> state isn't associated with an out of range condition. This helps me >>>>> to prevent some if-else-cascades and speeds up the code.[...]
So this is the complete function but i put two empty lines around the >>>>> code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it.
Sorry.
In the mean time, I am working on another fractal set to music. Like
these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Very impressive.
Thank you very much for the kind comment! :^)
Could use maybe a few more colours though.
Yeah, they could. Humm... I am working on another animation using a more >robust coloring algorithm for the field lines. Here is an example:
https://fractalforums.org/gallery/1612-300921002353.png
On Fri, 1 Oct 2021 13:11:21 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 2:17 AM, RadicalRabbit@theburrow.co.uk wrote:
On Thu, 30 Sep 2021 13:00:53 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>>>> be thrown. These states are all true or false so I combined them to a >>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>> state isn't associated with an out of range condition. This helps me >>>>>> to prevent some if-else-cascades and speeds up the code.[...]
So this is the complete function but i put two empty lines around the >>>>>> code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it. >>>>> Sorry.
In the mean time, I am working on another fractal set to music. Like
these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Very impressive.
Thank you very much for the kind comment! :^)
Could use maybe a few more colours though.
Yeah, they could. Humm... I am working on another animation using a more
robust coloring algorithm for the field lines. Here is an example:
https://fractalforums.org/gallery/1612-300921002353.png
That looks much more sophisticated.
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 6:07 AM, Branimir Maksimovic wrote:Safari, iCloud private relay.... ipv6
On 2021-09-30, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
An error occurred. Please try again later. (Playback ID: pHR4vgIqqp13ECHz) >>> Learn MoreOn 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>>>> be thrown. These states are all true or false so I combined them to a >>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>> state isn't associated with an out of range condition. This helps me >>>>>> to prevent some if-else-cascades and speeds up the code.[...]
So this is the complete function but i put two empty lines around the >>>>>> code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it. >>>>> Sorry.
In the mean time, I am working on another fractal set to music. Like
these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
That's odd. The links I posted work for me. Just checked them. Humm...
On 10/3/2021 1:25 AM, RadicalRabbit@theburrow.co.uk wrote:What about this (not mine work): https://www.icloud.com/iclouddrive/0sLxM6sxtszTkGEX_3YwH57bA#mandelbrot
On Fri, 1 Oct 2021 13:11:21 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 2:17 AM, RadicalRabbit@theburrow.co.uk wrote:
On Thu, 30 Sep 2021 13:00:53 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might >>>>>>> be thrown. These states are all true or false so I combined them to a >>>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>>> state isn't associated with an out of range condition. This helps me >>>>>>> to prevent some if-else-cascades and speeds up the code.[...]
So this is the complete function but i put two empty lines around the >>>>>>> code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it. >>>>>> Sorry.
In the mean time, I am working on another fractal set to music. Like >>>>> these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Very impressive.
Thank you very much for the kind comment! :^)
Could use maybe a few more colours though.
Yeah, they could. Humm... I am working on another animation using a more >>> robust coloring algorithm for the field lines. Here is an example:
https://fractalforums.org/gallery/1612-300921002353.png
That looks much more sophisticated.
It does! Thanks. Fwiw, here is another interesting zoom on a spiral
formation using the experimental coloring algorihtm:
https://fractalforums.org/gallery/1612-031021065422.png
Now, when I am finished with my new animation, I am going to cycle the
colors using an interpolation across the frames. It should look really strange, and mesmerizing. That's the goal. ;^)
Humm... Can you see any of my work on YouTube? Here is my channel:
https://www.youtube.com/channel/UC_DhsJu-AbQ6Msnxdf8z6Kg
Does that link work for you?
On 2021-10-03, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:[...]
On 10/3/2021 1:25 AM, RadicalRabbit@theburrow.co.uk wrote:What about this (not mine work): https://www.icloud.com/iclouddrive/0sLxM6sxtszTkGEX_3YwH57bA#mandelbrot proggy:
On Fri, 1 Oct 2021 13:11:21 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 2:17 AM, RadicalRabbit@theburrow.co.uk wrote:
On Thu, 30 Sep 2021 13:00:53 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception might[...]
be thrown. These states are all true or false so I combined them to a >>>>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>>>> state isn't associated with an out of range condition. This helps me >>>>>>>> to prevent some if-else-cascades and speeds up the code.
So this is the complete function but i put two empty lines around the >>>>>>>> code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it. >>>>>>> Sorry.
In the mean time, I am working on another fractal set to music. Like >>>>>> these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Very impressive.
Thank you very much for the kind comment! :^)
Could use maybe a few more colours though.
Yeah, they could. Humm... I am working on another animation using a more >>>> robust coloring algorithm for the field lines. Here is an example:
https://fractalforums.org/gallery/1612-300921002353.png
That looks much more sophisticated.
It does! Thanks. Fwiw, here is another interesting zoom on a spiral
formation using the experimental coloring algorihtm:
https://fractalforums.org/gallery/1612-031021065422.png
Now, when I am finished with my new animation, I am going to cycle the
colors using an interpolation across the frames. It should look really
strange, and mesmerizing. That's the goal. ;^)
format ELF64 executable 3
On 2021-10-03, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
Humm... Can you see any of my work on YouTube? Here is my channel:
https://www.youtube.com/channel/UC_DhsJu-AbQ6Msnxdf8z6Kg
Does that link work for you?
Bookmarked, will enjoy, THANKS!
On 10/3/2021 2:06 PM, Branimir Maksimovic wrote:
On 2021-10-03, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:[...]
On 10/3/2021 1:25 AM, RadicalRabbit@theburrow.co.uk wrote:What about this (not mine work):
On Fri, 1 Oct 2021 13:11:21 -0700 "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 2:17 AM, RadicalRabbit@theburrow.co.uk wrote:
On Thu, 30 Sep 2021 13:00:53 -0700 "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception >>>>>>>>> might be thrown. These states are all true or false so I combined >>>>>>>>> them to a four bit pattern wich I used as an index to a table which >>>>>>>>> stores the strings of the out_of_range exception to be trown or a >>>>>>>>> nullptr if the state isn't associated with an out of range condition. >>>>>>>>> This helps me to prevent some if-else-cascades and speeds up the >>>>>>>>> code. So this is the complete function but i put two empty lines >>>>>>>>> around the code I mentioned.[...]
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it. >>>>>>>> Sorry.
In the mean time, I am working on another fractal set to music. Like >>>>>>> these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Very impressive.
Thank you very much for the kind comment! :^)
Could use maybe a few more colours though.
Yeah, they could. Humm... I am working on another animation using a more >>>>> robust coloring algorithm for the field lines. Here is an example:
https://fractalforums.org/gallery/1612-300921002353.png
That looks much more sophisticated.
It does! Thanks. Fwiw, here is another interesting zoom on a spiral
formation using the experimental coloring algorihtm:
https://fractalforums.org/gallery/1612-031021065422.png
Now, when I am finished with my new animation, I am going to cycle the
colors using an interpolation across the frames. It should look really
strange, and mesmerizing. That's the goal. ;^)
https://www.icloud.com/iclouddrive/0sLxM6sxtszTkGEX_3YwH57bA#mandelbrot
proggy: format ELF64 executable 3
Definite field lines. Not sure if its using binary decomposition. Actually, check these out. Its from a field line algorithm I created for escape time fractals:
https://fractalforums.org/fractal-mathematics-and-new-theories/28/plotting-field-lines-during-iteration/4233
It was mentioned here:
https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_complex_plane/MandelbrotSetExteriorComplex_potential
Search for my last name in the page:
http://www.fractalforums.com/new-theories-and-research/plotting-field-lines-during-iteration/
No problem. Glad you can see them. Also, fwiw, here is my vector field rendered in real time using a GLSL shader:Both work on Safari, thanks.
https://www.shadertoy.com/view/MdcyRs
You can press and drag a point around in the animation to create an attractor in the field. Also, he is my field using WebGL:
http://fractallife247.com/test/webgl/
Does it work for you? Thanks.
Am 25.09.2021 um 19:22 schrieb Branimir Maksimovic:
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
I am just asking because you build something
And you use unreliable function for that?
Show me where my code is unreliable.
I think you're simply a poor troll.
on shaken ground. Why do you think is reliable,
simple question?
Because the code is simple.
On 9/25/2021 8:46 PM, Bonita Montero wrote:
Am 25.09.2021 um 19:22 schrieb Branimir Maksimovic:
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
I am just asking because you build something
And you use unreliable function for that?
Show me where my code is unreliable.
I think you're simply a poor troll.
on shaken ground. Why do you think is reliable,
simple question?
Because the code is simple.
Have you posted the entire code for your dual_monitor algorihtm?
On 9/25/2021 8:46 PM, Bonita Montero wrote:
Am 25.09.2021 um 19:22 schrieb Branimir Maksimovic:
On 2021-09-25, Bonita Montero <Bonita....@gmail.com> wrote:
I am just asking because you build something
And you use unreliable function for that?
Show me where my code is unreliable.
I think you're simply a poor troll.
on shaken ground. Why do you think is reliable,
simple question?
Because the code is simple.
Have you posted the entire code for your dual_monitor algorihtm?
Am 04.10.2021 um 10:19 schrieb Chris M. Thomasson:
On 9/25/2021 8:46 PM, Bonita Montero wrote:
Am 25.09.2021 um 19:22 schrieb Branimir Maksimovic:
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
I am just asking because you build something
And you use unreliable function for that?
Show me where my code is unreliable.
I think you're simply a poor troll.
on shaken ground. Why do you think is reliable,
simple question?
Because the code is simple.
Have you posted the entire code for your dual_monitor algorihtm?
You won't understand it.
On Monday, 4 October 2021 at 11:20:13 UTC+3, Chris M. Thomasson wrote:
On 9/25/2021 8:46 PM, Bonita Montero wrote:
Am 25.09.2021 um 19:22 schrieb Branimir Maksimovic:
On 2021-09-25, Bonita Montero <Bonita....@gmail.com> wrote:
I am just asking because you build something
And you use unreliable function for that?
Show me where my code is unreliable.
I think you're simply a poor troll.
on shaken ground. Why do you think is reliable,
simple question?
Because the code is simple.
Have you posted the entire code for your dual_monitor algorihtm?
BMs threads are busily spinning when nothing to do so
it is hard to find utilization to it (besides of as bad example).
Am 02.10.2021 um 09:32 schrieb Chris M. Thomasson:
On 10/2/2021 12:30 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson:
A mutex isn't a lock-free structure because is _also_ has a
slow path.
It can have a very nice fast-path... Have you ever created one?
That's not what we're talking about.
I am talking about the nice fast-path being totally lock/wait-free. It
can! Think about it some more.
Lock-free is when you only have a fast path - and no slow path.
On 10/2/2021 1:27 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:32 schrieb Chris M. Thomasson:
On 10/2/2021 12:30 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson:
A mutex isn't a lock-free structure because is _also_ has a
slow path.
It can have a very nice fast-path... Have you ever created one?
That's not what we're talking about.
I am talking about the nice fast-path being totally lock/wait-free.
It can! Think about it some more.
Lock-free is when you only have a fast path - and no slow path.
Why not combine the two? Ahhh, the futex, or eventcount.
Am 04.10.2021 um 20:31 schrieb Chris M. Thomasson:
On 10/2/2021 1:27 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:32 schrieb Chris M. Thomasson:
On 10/2/2021 12:30 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson:
A mutex isn't a lock-free structure because is _also_ has a
slow path.
It can have a very nice fast-path... Have you ever created one?
That's not what we're talking about.
I am talking about the nice fast-path being totally lock/wait-free.
It can! Think about it some more.
Lock-free is when you only have a fast path - and no slow path.
Why not combine the two? Ahhh, the futex, or eventcount.
Then it's not lock-free anymore.
On 2021-10-03, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/3/2021 2:06 PM, Branimir Maksimovic wrote:Found, THANKS!
On 2021-10-03, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 10/3/2021 1:25 AM, RadicalRabbit@theburrow.co.uk wrote:[...]
What about this (not mine work):On Fri, 1 Oct 2021 13:11:21 -0700 "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:
On 10/1/2021 2:17 AM, RadicalRabbit@theburrow.co.uk wrote:
On Thu, 30 Sep 2021 13:00:53 -0700 "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:
On 9/29/2021 12:09 PM, Chris M. Thomasson wrote:
On 9/20/2021 1:43 PM, Bonita Montero wrote:
In some code I've to check different sates for which an exception >>>>>>>>>> might be thrown. These states are all true or false so I combined >>>>>>>>>> them to a four bit pattern wich I used as an index to a table which >>>>>>>>>> stores the strings of the out_of_range exception to be trown or a >>>>>>>>>> nullptr if the state isn't associated with an out of range condition.[...]
This helps me to prevent some if-else-cascades and speeds up the >>>>>>>>>> code. So this is the complete function but i put two empty lines >>>>>>>>>> around the code I mentioned.
void dual_monitor::wait( bool b )
Have you posted the whole dual_monitor code? If you did, I missed it. >>>>>>>>> Sorry.
In the mean time, I am working on another fractal set to music. Like >>>>>>>> these I did last year:
https://youtu.be/DSiWvF5QOiI
https://youtu.be/QFPSYsYUKBA
Very impressive.
Thank you very much for the kind comment! :^)
Could use maybe a few more colours though.
Yeah, they could. Humm... I am working on another animation using a more >>>>>> robust coloring algorithm for the field lines. Here is an example: >>>>>>
https://fractalforums.org/gallery/1612-300921002353.png
That looks much more sophisticated.
It does! Thanks. Fwiw, here is another interesting zoom on a spiral
formation using the experimental coloring algorihtm:
https://fractalforums.org/gallery/1612-031021065422.png
Now, when I am finished with my new animation, I am going to cycle the >>>> colors using an interpolation across the frames. It should look really >>>> strange, and mesmerizing. That's the goal. ;^)
https://www.icloud.com/iclouddrive/0sLxM6sxtszTkGEX_3YwH57bA#mandelbrot
proggy: format ELF64 executable 3
Definite field lines. Not sure if its using binary decomposition. Actually, >> check these out. Its from a field line algorithm I created for escape time >> fractals:
https://fractalforums.org/fractal-mathematics-and-new-theories/28/plotting-field-lines-during-iteration/4233
It was mentioned here:
https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_complex_plane/MandelbrotSetExteriorComplex_potential
Search for my last name in the page:
http://www.fractalforums.com/new-theories-and-research/plotting-field-lines-during-iteration/
Am 02.10.2021 um 10:36 schrieb Chris M. Thomasson:
Why do you make me want to cough when I read some of your comments?
The idea is to try to minimize slow-paths... Think about it! Damn
it... ;^o
The idea of lock-free algorithms is not to have slow paths at all.
Otherwise they wouldn't be lock-free.
So lock/wait free algorithms are of great use! Not, what did you say,
idiotic? Wow.
No, lock-free algortims involve polling because there is never any kernel-waiting. And polling is out of question.
Am 02.10.2021 um 13:06 schrieb Bonita Montero:
Am 02.10.2021 um 12:03 schrieb Chris M. Thomasson:
Lock-free stacks are used for pooling or handling back resoruces to an >>>> owning thread.
Really, is that their only use? ..
Yes.
Or more precisely: pracitcally yes. Because other uses aren't
practicable because of the drawbacks of lock-free algorithms.
ideal. A wait-free fast-path is even better!
No problem. Fwiw, here is a new test animation I made:Watched, beautiful
https://youtu.be/nPR4xK-5i4I
https://www.youtube.com/watch?v=nPR4xK-5i4I
Both links work for me. How many work for you? Just wondering.
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
ideal. A wait-free fast-path is even better!Then, you have to think what to do, when there is is nothing
to do :P
On 10/6/2021 7:17 PM, Branimir Maksimovic wrote:
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
ideal. A wait-free fast-path is even better!Then, you have to think what to do, when there is is nothing
to do :P
When the fast-path fails, we can choose to try to wait. Usually on a
Futex or Eventcount. The main idea is under periods of load, when the structure is not empty, we can fly along lock/wait-free paths.
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/6/2021 7:17 PM, Branimir Maksimovic wrote:
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> ideal. A wait-free fast-path is even better!
Then, you have to think what to do, when there is is nothing
to do :P
When the fast-path fails, we can choose to try to wait. Usually on a
Futex or Eventcount. The main idea is under periods of load, when the
structure is not empty, we can fly along lock/wait-free paths.
iWhat you think about this code:
while(true){
usleep(1000) /// we dpn't want to overheat :P
/***
* interrestingly CAS doesn't work, because of
* some weird Apple memory scheme.
* OSAtomicCompareAndSwapPtr: doesn't work
*/
var val:UInt8 = 0
repeat {
usleep(1)
OSMemoryBarrier()
val = bval!.pointee!.load(as:UInt8.self)
}while ( val == 1 || val == 2)
OSMemoryBarrier()
bval!.pointee!.storeBytes(of:1,as: UInt8.self)
repeat {
usleep(1)
OSMemoryBarrier()
val = bval!.pointee!.load(as:UInt8.self)
}while ( val == 2)
OSMemoryBarrier()
bval!.pointee!.storeBytes(of:2,as: UInt8.self)
print("acquired")
/// payLoad
OSMemoryBarrier()
bval!.pointee!.storeBytes(of:0,as: UInt8.self)
print("releazed\n")
order? Humm... I cannot believe that CAS does not work! What does std::atomic<T>::compare_exchange_weak() with a membar of std::memory_order_relaxed disassemble into?Problem is OS, how it maps memory. I didn't figured out why,
On 10/2/2021 1:57 AM, Bonita Montero wrote:
Am 02.10.2021 um 10:36 schrieb Chris M. Thomasson:
Why do you make me want to cough when I read some of your comments?
The idea is to try to minimize slow-paths... Think about it! Damn
it... ;^o
The idea of lock-free algorithms is not to have slow paths at all.
Why not? You have a very narrow view. A pure lock-free fast-path is
ideal. A wait-free fast-path is even better!
On 10/4/2021 10:13 PM, Bonita Montero wrote:
Am 04.10.2021 um 20:31 schrieb Chris M. Thomasson:
On 10/2/2021 1:27 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:32 schrieb Chris M. Thomasson:
On 10/2/2021 12:30 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson:
A mutex isn't a lock-free structure because is _also_ has a
slow path.
It can have a very nice fast-path... Have you ever created one?
That's not what we're talking about.
I am talking about the nice fast-path being totally lock/wait-free.
It can! Think about it some more.
Lock-free is when you only have a fast path - and no slow path.
Why not combine the two? Ahhh, the futex, or eventcount.
Then it's not lock-free anymore.
However, it has lock-free fast-paths. That is a huge advantage!
Am 06.10.2021 um 21:22 schrieb Chris M. Thomasson:
On 10/4/2021 10:13 PM, Bonita Montero wrote:
Am 04.10.2021 um 20:31 schrieb Chris M. Thomasson:
On 10/2/2021 1:27 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:32 schrieb Chris M. Thomasson:
On 10/2/2021 12:30 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson:
That's not what we're talking about.A mutex isn't a lock-free structure because is _also_ has a
slow path.
It can have a very nice fast-path... Have you ever created one? >>>>>>>
I am talking about the nice fast-path being totally
lock/wait-free. It can! Think about it some more.
Lock-free is when you only have a fast path - and no slow path.
Why not combine the two? Ahhh, the futex, or eventcount.
Then it's not lock-free anymore.
However, it has lock-free fast-paths. That is a huge advantage!
Then you could call every mutex lock-free. But no one does that.
Am 07.10.2021 um 02:19 schrieb Chris M. Thomasson:
On 10/2/2021 1:57 AM, Bonita Montero wrote:
Am 02.10.2021 um 10:36 schrieb Chris M. Thomasson:
Why do you make me want to cough when I read some of your comments?
The idea is to try to minimize slow-paths... Think about it! Damn
it... ;^o
The idea of lock-free algorithms is not to have slow paths at all.
Why not? You have a very narrow view. A pure lock-free fast-path is
ideal. A wait-free fast-path is even better!
That's not a narrow view but it is how it's defined.
No problem. Fwiw, here is a new test animation I made:
https://youtu.be/nPR4xK-5i4I
https://www.youtube.com/watch?v=nPR4xK-5i4I
Both links work for me. How many work for you? Just wondering.
That's not a narrow view but it is how it's defined.
Yeah... Think outside of the box and use a lock/wait-free algorihtm
for a fast-path, and use a Futex or Eventcount for the slow-path.
On 10/6/2021 11:36 PM, Bonita Montero wrote:
Am 06.10.2021 um 21:22 schrieb Chris M. Thomasson:
On 10/4/2021 10:13 PM, Bonita Montero wrote:
Am 04.10.2021 um 20:31 schrieb Chris M. Thomasson:
On 10/2/2021 1:27 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:32 schrieb Chris M. Thomasson:
On 10/2/2021 12:30 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson:
That's not what we're talking about.A mutex isn't a lock-free structure because is _also_ has a >>>>>>>>>> slow path.
It can have a very nice fast-path... Have you ever created one? >>>>>>>>
I am talking about the nice fast-path being totally
lock/wait-free. It can! Think about it some more.
Lock-free is when you only have a fast path - and no slow path.
Why not combine the two? Ahhh, the futex, or eventcount.
Then it's not lock-free anymore.
However, it has lock-free fast-paths. That is a huge advantage!
Then you could call every mutex lock-free. But no one does that.
You can call access to an unlocked mutex a fast-path.
Am 07.10.2021 um 09:31 schrieb Chris M. Thomasson:
On 10/6/2021 11:36 PM, Bonita Montero wrote:
Am 06.10.2021 um 21:22 schrieb Chris M. Thomasson:
On 10/4/2021 10:13 PM, Bonita Montero wrote:
Am 04.10.2021 um 20:31 schrieb Chris M. Thomasson:
On 10/2/2021 1:27 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:32 schrieb Chris M. Thomasson:
On 10/2/2021 12:30 AM, Bonita Montero wrote:
Am 02.10.2021 um 09:20 schrieb Chris M. Thomasson:
That's not what we're talking about.A mutex isn't a lock-free structure because is _also_ has a >>>>>>>>>>> slow path.
It can have a very nice fast-path... Have you ever created one? >>>>>>>>>
I am talking about the nice fast-path being totally
lock/wait-free. It can! Think about it some more.
Lock-free is when you only have a fast path - and no slow path.
Why not combine the two? Ahhh, the futex, or eventcount.
Then it's not lock-free anymore.
However, it has lock-free fast-paths. That is a huge advantage!
Then you could call every mutex lock-free. But no one does that.
You can call access to an unlocked mutex a fast-path.
Yes, but because of that fast path a mutex isn't lock-free.
You say that everything having a fast path could be called lock-free.
Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
That's not a narrow view but it is how it's defined.
Yeah... Think outside of the box and use a lock/wait-free algorihtm
for a fast-path, and use a Futex or Eventcount for the slow-path.
Lock-free algorithms don't have a slow path.
That's while they don't lock and you've to poll them.
Well only thing you can do is sleep not to overheat :PYes, but because of that fast path a mutex isn't lock-free.
You say that everything having a fast path could be called lock-free.
I am saying the fast-path is lock/wait-free. Then there is the
slow-path... A completely different story. A futex and eventcount are
used to allow the data-structure to be waited on. A futex is much lower
level than eventcount. An eventcount is kind of akin to a condvar for lock/wait-free algorithms. A futex can be used to build an eventcount.
On 10/7/2021 3:16 AM, Bonita Montero wrote:Yeah, problem is when you don't have something usefull to do :P
Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
That's not a narrow view but it is how it's defined.
Yeah... Think outside of the box and use a lock/wait-free algorihtm
for a fast-path, and use a Futex or Eventcount for the slow-path.
Lock-free algorithms don't have a slow path.
That's while they don't lock and you've to poll them.
Why poll them? Add a slow-path using futex or eventcount... Is seems
that you are having a hard time understanding this... This keeps the fast-path for periods of load, when sheer performance matters. Under
load, the data-structure is much more likely to hit fast-paths, and reap
the benefits from lock/wait free algorithms. Got it?
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/7/2021 3:16 AM, Bonita Montero wrote:Yeah, problem is when you don't have something usefull to do :P
Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
That's not a narrow view but it is how it's defined.
Yeah... Think outside of the box and use a lock/wait-free algorihtm
for a fast-path, and use a Futex or Eventcount for the slow-path.
Lock-free algorithms don't have a slow path.
That's while they don't lock and you've to poll them.
Why poll them? Add a slow-path using futex or eventcount... Is seems
that you are having a hard time understanding this... This keeps the
fast-path for periods of load, when sheer performance matters. Under
load, the data-structure is much more likely to hit fast-paths, and reap
the benefits from lock/wait free algorithms. Got it?
On 10/7/2021 1:16 PM, Branimir Maksimovic wrote:You have *understanding* :P
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/7/2021 3:16 AM, Bonita Montero wrote:Yeah, problem is when you don't have something usefull to do :P
Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
That's not a narrow view but it is how it's defined.
Yeah... Think outside of the box and use a lock/wait-free algorihtm for >>>>> a fast-path, and use a Futex or Eventcount for the slow-path.
Lock-free algorithms don't have a slow path. That's while they don't lock >>>> and you've to poll them.
Why poll them? Add a slow-path using futex or eventcount... Is seems that >>> you are having a hard time understanding this... This keeps the fast-path >>> for periods of load, when sheer performance matters. Under load, the
data-structure is much more likely to hit fast-paths, and reap the benefits >>> from lock/wait free algorithms. Got it?
Indeed. There is a funny way to use try_lock to try to gain this sort of pattern... Iirc, it went something like: __________________________ void lock() { while (! try_lock()) { if (! try_to_do_something_else()) { lock(); break; } } } __________________________
So, if something else was done, we can try_lock again. Iirc, I even put a limit on how many times try_lock() can be called. Akin to an adaptive mutex, except instead of spinning, we see if something else can be done.
It does work in certain scenarios and/or setups...
On 10/7/2021 3:16 AM, Bonita Montero wrote:
Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
That's not a narrow view but it is how it's defined.
Yeah... Think outside of the box and use a lock/wait-free algorihtm
for a fast-path, and use a Futex or Eventcount for the slow-path.
Lock-free algorithms don't have a slow path.
That's while they don't lock and you've to poll them.
Why poll them? ...
Add a slow-path using futex or eventcount...
I am saying the fast-path is lock/wait-free.
Am 07.10.2021 um 21:21 schrieb Chris M. Thomasson:
I am saying the fast-path is lock/wait-free.
No one calls sth. with a fast path and a slow path lock-free.
Lock-free is _only_ without a slow path. Idiot !
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
order? Humm... I cannot believe that CAS does not work! What doesProblem is OS, how it maps memory. I didn't figured out why,
std::atomic<T>::compare_exchange_weak() with a membar of
std::memory_order_relaxed disassemble into?
but simply value is not readed, that is, if I do it in assembler,
it would probably work, but I have tried to do it in HLL :P
This is M1, but I think it is more related to OS...
Haven't tried C++ though :P
On 2021-10-03, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
No problem. Glad you can see them. Also, fwiw, here is my vector fieldBoth work on Safari, thanks.
rendered in real time using a GLSL shader:
https://www.shadertoy.com/view/MdcyRs
You can press and drag a point around in the animation to create an attractor
in the field. Also, he is my field using WebGL:
http://fractallife247.com/test/webgl/
Does it work for you? Thanks.
Am 07.10.2021 um 21:26 schrieb Chris M. Thomasson:
On 10/7/2021 3:16 AM, Bonita Montero wrote:
Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
That's not a narrow view but it is how it's defined.
Yeah... Think outside of the box and use a lock/wait-free algorihtm
for a fast-path, and use a Futex or Eventcount for the slow-path.
Lock-free algorithms don't have a slow path.
That's while they don't lock and you've to poll them.
Why poll them? ...
Because they are lock-free.
Add a slow-path using futex or eventcount...
Then they aren't lock-free anymore.
On 07/10/2021 14:11, Chris M. Thomasson wrote:
No problem. Fwiw, here is a new test animation I made:
https://youtu.be/nPR4xK-5i4I
https://www.youtube.com/watch?v=nPR4xK-5i4I
Both links work for me. How many work for you? Just wondering.
Cool!
On 10/7/2021 1:16 PM, Branimir Maksimovic wrote:^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/7/2021 3:16 AM, Bonita Montero wrote:Yeah, problem is when you don't have something usefull to do :P
Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
That's not a narrow view but it is how it's defined.
Yeah... Think outside of the box and use a lock/wait-free algorihtm
for a fast-path, and use a Futex or Eventcount for the slow-path.
Lock-free algorithms don't have a slow path.
That's while they don't lock and you've to poll them.
Why poll them? Add a slow-path using futex or eventcount... Is seems
that you are having a hard time understanding this... This keeps the
fast-path for periods of load, when sheer performance matters. Under
load, the data-structure is much more likely to hit fast-paths, and reap >>> the benefits from lock/wait free algorithms. Got it?
Indeed. There is a funny way to use try_lock to try to gain this sort of pattern... Iirc, it went something like:
__________________________
void lock()
{
while (! try_lock())
{
if (! try_to_do_something_else())
{
lock();
break;
}
}
}
__________________________
So, if something else was done, we can try_lock again. Iirc, I even put
a limit on how many times try_lock() can be called. Akin to an adaptive mutex, except instead of spinning, we see if something else can be done.
It does work in certain scenarios and/or setups...
On 10/2/2021 4:07 AM, Bonita Montero wrote:
Am 02.10.2021 um 13:06 schrieb Bonita Montero:
Am 02.10.2021 um 12:03 schrieb Chris M. Thomasson:
Lock-free stacks are used for pooling or handling back resoruces to an >>>>> owning thread.
Really, is that their only use? ..
Yes.
Or more precisely: pracitcally yes. Because other uses aren't
practicable because of the drawbacks of lock-free algorithms.
think outside of the box.
On 10/3/2021 9:44 PM, Branimir Maksimovic wrote:Works! thanks!
On 2021-10-03, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
No problem. Glad you can see them. Also, fwiw, here is my vector fieldBoth work on Safari, thanks.
rendered in real time using a GLSL shader:
https://www.shadertoy.com/view/MdcyRs
You can press and drag a point around in the animation to create an attractor
in the field. Also, he is my field using WebGL:
http://fractallife247.com/test/webgl/
Does it work for you? Thanks.
I am glad they work for you! Thanks for taking the time to give them a
go. Now, I am wondering if the following program of mine works on Safari
on your end. Iirc, it works on Safari for windows... ;^)
Its a highly experimental field based DLA algorihtm I created. Let it
run for around a half a minute or so. Then try to click around in the
field, and see what happens... A click should create a new attractor and start influencing the field in real time. Keep in mind that the
particles are following field lines instead of using random walks. This
is different than "traditional" DLA:
http://fractallife247.com/fdla/
Fwiw, here is a decent description of DLA:
https://en.wikipedia.org/wiki/Diffusion-limited_aggregation
Thanks.
So allowing a fast and a slow path gives the best of both worlds.
Am I talking to a complete idiot here ?
We're not discussing what's the best while synchronizing threads
but what's lock-free and what's not. And having a slow path makes
an algorithm not lock-free.
Read the WP-article: https://en.wikipedia.org/wiki/Non-blocking_algorithm : "In computer science, an algorithm is called non-blocking
if failure or suspension of any thread cannot cause failure
_or suspension of another thread_".
Am 07.10.2021 um 03:22 schrieb Chris M. Thomasson:
On 10/2/2021 4:07 AM, Bonita Montero wrote:
Am 02.10.2021 um 13:06 schrieb Bonita Montero:
Am 02.10.2021 um 12:03 schrieb Chris M. Thomasson:
Lock-free stacks are used for pooling or handling back resoruces
to an
owning thread.
Really, is that their only use? ..
Yes.
Or more precisely: pracitcally yes. Because other uses aren't
practicable because of the drawbacks of lock-free algorithms.
think outside of the box.
Any algorihm having a slow path isn't
lock free because the slow path locks.
So allowing a fast and a slow path gives the best of both worlds.
On 2021-10-08, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 10/3/2021 9:44 PM, Branimir Maksimovic wrote:Works! thanks!
On 2021-10-03, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> No problem. Glad you can see them. Also, fwiw, here is my vector field >>>> rendered in real time using a GLSL shader:
Both work on Safari, thanks.
https://www.shadertoy.com/view/MdcyRs
You can press and drag a point around in the animation to create an attractor
in the field. Also, he is my field using WebGL:
http://fractallife247.com/test/webgl/
Does it work for you? Thanks.
I am glad they work for you! Thanks for taking the time to give them a
go. Now, I am wondering if the following program of mine works on Safari
on your end. Iirc, it works on Safari for windows... ;^)
Its a highly experimental field based DLA algorihtm I created. Let it
run for around a half a minute or so. Then try to click around in the
field, and see what happens... A click should create a new attractor and
start influencing the field in real time. Keep in mind that the
particles are following field lines instead of using random walks. This
is different than "traditional" DLA:
http://fractallife247.com/fdla/
Fwiw, here is a decent description of DLA:
https://en.wikipedia.org/wiki/Diffusion-limited_aggregation
Thanks.
Am 09.10.2021 um 22:13 schrieb Chris M. Thomasson:
On 10/9/2021 12:59 PM, Bonita Montero wrote:
So allowing a fast and a slow path gives the best of both worlds.
Am I talking to a complete idiot here ?
We're not discussing what's the best while synchronizing threads
but what's lock-free and what's not. And having a slow path makes
an algorithm not lock-free.
Read the WP-article:
https://en.wikipedia.org/wiki/Non-blocking_algorithm :
"In computer science, an algorithm is called non-blocking
if failure or suspension of any thread cannot cause failure
_or suspension of another thread_".
You think lock-free is crap. ...
Everything lock-free except from lock-free stacks is crap.
On 10/9/2021 12:59 PM, Bonita Montero wrote:
So allowing a fast and a slow path gives the best of both worlds.
Am I talking to a complete idiot here ?
We're not discussing what's the best while synchronizing threads
but what's lock-free and what's not. And having a slow path makes
an algorithm not lock-free.
Read the WP-article:
https://en.wikipedia.org/wiki/Non-blocking_algorithm :
"In computer science, an algorithm is called non-blocking
if failure or suspension of any thread cannot cause failure
_or suspension of another thread_".
You think lock-free is crap. ...
Nice work of art, show me more !Thanks.Works! thanks!
Perfect! All right. Cool. Thanks again. Btw, I made a new test animation
in 3d:
https://www.youtube.com/watch?v=2gznap7wLeQ
On 2021-10-10, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
Nice work of art, show me more !Thanks.Works! thanks!
Perfect! All right. Cool. Thanks again. Btw, I made a new test animation
in 3d:
https://www.youtube.com/watch?v=2gznap7wLeQ
Thanks!
Fwiw, Here is a new, highly experimental animation of one of my
biomorphic fractal algorithms using rings comprised of tori. Next
version will have some music! ;^)
Well, what do you think?
https://youtu.be/3abgNkpIY98
https://www.youtube.com/watch?v=3abgNkpIY98
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 112 |
| Nodes: | 8 (1 / 7) |
| Uptime: | 26:15:49 |
| Calls: | 2,468 |
| Files: | 8,627 |
| Messages: | 1,892,288 |
