09.12.2015 13:28, Dimitry Sibiryakov wrote:
> 09.12.2015 12:17, Vlad Khorsun wrote:
..
>> PS What is your goal asking this questions ? All reasons was already
>> explained, even more...
>> Are you want us to write not robust code just to make it more simple for
>> your eye ?
>
> InterlockedOr
09.12.2015 12:17, Vlad Khorsun wrote:
> We spent a lot of time for nothing in this thread (not only in this...).
BTW, no offense, but between time spent by a single writer to write comment
why simple
code cannot work in this case and time spent by multiple readers trying to
understand
"what
09.12.2015 12:17, Vlad Khorsun wrote:
> 09.12.2015 12:49, Dimitry Sibiryakov wrote:
>> 08.12.2015 23:26, Vlad Khorsun wrote:
1) allowSweepThread() set DBB_sweep_starting
>>> Then code attempts to start sweep thread. Which could fail.
>>
>> If start thread fail, clearSweepFlags() wil
09.12.2015 12:49, Dimitry Sibiryakov wrote:
> 08.12.2015 23:26, Vlad Khorsun wrote:
>>> 1) allowSweepThread() set DBB_sweep_starting
>> Then code attempts to start sweep thread. Which could fail.
>
> If start thread fail, clearSweepFlags() will be called, clearing both
> flags.
You fo
08.12.2015 23:26, Vlad Khorsun wrote:
>> 1) allowSweepThread() set DBB_sweep_starting
> Then code attempts to start sweep thread. Which could fail.
If start thread fail, clearSweepFlags() will be called, clearing both flags.
May be you mean failed sweeper attach? Yes, this case will leav
08.12.2015 19:09, Dimitry Sibiryakov wrote:
> 08.12.2015 17:45, Vlad Khorsun wrote:
...
>> Note, cleanSweepFlags() is never called after
>> Database::allowSweepThread(). It is called after
>> another method - Database::allowSweepRun()
>
> Which is called after allowSweepThread(). Total s
08.12.2015 17:45, Vlad Khorsun wrote:
> I see no races there. Especially considering another flags.
Yeah, my bad.
> This code must not set DBB_sweep_starting flag if it not going to start
> sweep thread.
> I.e. if sweep thread:
> - already starting
In this case flag DBB_sweep_starting
08.12.2015 18:25, Dimitry Sibiryakov wrote:
...
> IMHO, on contrary, it is quite common case when several threads want to
> perform an
> operation but only is allowed to.
> In this topic's example it is running a sweep process. When a thread want
> to run it,
> there can be two cases:
> a
08.12.2015 17:29, Jim Starkey wrote:
> In virtual all cases involving updates of non-interlocked data structures,
> the logic is -- and must be:
>
> for (;;)
> {
> state>
>
> if ()
>
>
> if ()
>
> }
>
> About the only ex
08.12.2015 16:41, Dimitry Sibiryakov wrote:
> 08.12.2015 15:31, Vlad Khorsun wrote:
>> This code is not the same as code that you blamed and it is not correct
>> at all.
>
> At first, I don't blame your code. It is robust and fast enough. It is
> just a little
Good to know, i had ano
On 12/8/2015 11:25 AM, Dimitry Sibiryakov wrote:
> 08.12.2015 17:12, Jim Starkey wrote:
>> But I don't get the logic that saving 10 ns. is worth introducing a
>> bug.
> Could you elaborate what bug you have on mind?
>
>> I suppose there are cases where you want to set a bit and don't
>> care
08.12.2015 17:12, Jim Starkey wrote:
> But I don't get the logic that saving 10 ns. is worth introducing a
> bug.
Could you elaborate what bug you have on mind?
> I suppose there are cases where you want to set a bit and don't
> care whether it was already set are diminishingly small -- and
>
Don't worry about transient compare-and-swap failures. If you do some
testing, you will find that read-read conflicts are common.
But I don't get the logic that saving 10 ns. is worth introducing a
bug. I suppose there are cases where you want to set a bit and don't
care whether it was alread
08.12.2015 16:29, Jim Starkey wrote:
> In virtual all cases involving updates of non-interlocked data structures,
> the logic is --
> and must be:
Unfortunately, this logic doesn't work quite well for bit flags.
Consider two threads, setting flags A and B respectively.
> for (;;)
>
In virtual all cases involving updates of non-interlocked data
structures, the logic is -- and must be:
for (;;)
{
if ()
if ()
}
About the only exceptions are interlocked increment and decrement for
very simple operations.
08.12.2015 15:31, Vlad Khorsun wrote:
> This code is not the same as code that you blamed and it is not correct
> at all.
At first, I don't blame your code. It is robust and fast enough. It is just
a little
confusing at first glance and leave some more room for threads racing if you
tak
08.12.2015 16:09, Dimitry Sibiryakov wrote:
> 08.12.2015 14:56, Vlad Khorsun wrote:
>> Do you see the principal difference with Firebird asm code i show ?
>
> Principal difference - no. Size difference - yes.
If we will support all existing intrinsic - do you think our code will be
sma
08.12.2015 14:56, Vlad Khorsun wrote:
> Do you see the principal difference with Firebird asm code i show ?
Principal difference - no. Size difference - yes.
> Do you see the loop with compare_exchange ?
Yes.
> Do you see the "lock or" operation ?
Yes.
> Do you still have questio
08.12.2015 14:53, Dimitry Sibiryakov пишет:
> 08.12.2015 13:39, Vlad Khorsun wrote:
>> I don't know how to guarantee atomic execution of sequence of two
>> instructions on Intel HW.
>
> Don't be confused by pseudocode in function description.
I'm not confused
>> You have a proof
08.12.2015 13:39, Vlad Khorsun wrote:
>I don't know how to guarantee atomic execution of sequence of two
> instructions on Intel HW.
Don't be confused by pseudocode in function description.
> You have a proof of course...
Test program from your link.
MSVC assembler:
> ; Line 7
08.12.2015 14:08, Dimitry Sibiryakov wrote:
> 08.12.2015 12:29, Vlad Khorsun wrote:
>> Note, with MSVC, when return value of _InterlockedOr() intrinsic is
>> used by the caller, compiler will
>> generate almost the same code as above (with a loop and compare_exchange).
>
> Yes, but they d
08.12.2015 12:29, Vlad Khorsun wrote:
> Note, with MSVC, when return value of _InterlockedOr() intrinsic is used
> by the caller, compiler will
> generate almost the same code as above (with a loop and compare_exchange).
Yes, but they do it on assembler level.
> But __sync_fetch_and_or()
08.12.2015 12:26, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Currently to do subj, code like this is used:
>
>> while (true)
>> {
>> AtomicCounter::counter_type old = dbb_flags;
>> if ((old & (DBB_sweep_in_progress |
>> D
08.12.2015 11:26, Dimitry Sibiryakov wrote:
> Is there a reason not to use _InterlockedOr() intrinsic with MSVC and
> __sync_or_and_fetch() with GCC for such cases?
Pardon, __synch_fetch_and_or(), of course,
--
WBR, SD.
-
Hello, All.
Currently to do subj, code like this is used:
> while (true)
> {
> AtomicCounter::counter_type old = dbb_flags;
> if ((old & (DBB_sweep_in_progress |
> DBB_sweep_starting)) || (dbb_ast_flags & DBB_shutdown)
25 matches
Mail list logo
