08.12.2015 1:39, Carlos H. Cantu wrote:
> I guess the proposed
> enhancement will be useful for 99% of the cases, when user don't care
> about loosing some accuracy in the middle of the calculation, but
> still cares about accuracy of stored data (what you store is exactly
> what you get when you
On 08/12/2015 08:29, Mark Rotteveel wrote:
> I'd prefer if anything is changed, this is not done without resorting
> hackish solutions that will just create another set of confusion, but
> instead by using generally accepted arbitrary precision decimal
> calculation rules from standards like
MR> The SQL Standard - intentionally - does not specify behavior for
MR> division. When dialect 3 was implemented, Borland opted to use the same
MR> rules as the SQL standard specifies for multiplication.
Thanks Borland
MR> I'm not so sure this is so easy to do. You either have additional space
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 |
>>
On 8-12-2015 11:37, Adriano dos Santos Fernandes wrote:
> On 08/12/2015 08:29, Mark Rotteveel wrote:
>> I'd prefer if anything is changed, this is not done without resorting
>> hackish solutions that will just create another set of confusion, but
>> instead by using generally accepted arbitrary
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
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
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 &
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.
SS> OK, can you make example how engine (with you extension) will handle this:
SS> select 1.0 / 1.00 from rdb$database
SS> select 0.1 / 9.00 from rdb$database
SS> select 1.1 / 0.01 from rdb$database
There is no such thing like "my extension". I
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 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
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 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
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
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
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
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
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
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
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:
>
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
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 (;;)
>
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
On Sun, Dec 6, 2015, at 19:00, Leyne, Sean wrote:
> This seems worthy of a Tracker case, no?
I agree.
BTW given it's a set of tests for .NET provider it's extremely easy to
replicate. Something I can help you with to pinpoint the issue?
--
Mgr. Jiří Činčura
Independent IT Specialist
08.12.2015 21:00, Carlos H. Cantu wrote:
> I'll let any core developer to answer you, since I don't know the reason for
> the two files.
Look at build scripts which one is used during build.
PS: In Firebird 3 there is only one file.
--
WBR, SD.
08.12.2015 13:29, Mark Rotteveel wrote:
> I'd prefer if anything is changed, this is not done without resorting
> hackish solutions that will just create another set of confusion, but
> instead by using generally accepted arbitrary precision decimal
> calculation rules from standards like ANSI
Title: Re: [Firebird-devel] Firebird #.## msg file
Mario,
I'll let any core developer to answer you, since I don't know the reason for the two files.
PS: I do not code in C/C++, so I participate in this list mostly as a listener. So, directing your messages to me, here, probably is not a good
>> select 1.0 / 1.00 from rdb$database
DY> I suppose this particular case (and maybe some others of the same kind)
DY> can be worked around. Perhaps we could truncate intermediate results to
DY> fit the maximum supported bitness if and only if the trailing bytes are
DY>
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
07.12.2015 19:21, Carlos H. Cantu wrote:
> With currently logic, the result of multiplications or divisions will
> have Scale = Sum of the scale of its members. This cause nonsense
> situations like the following:
>
> select 1.0 / 1.00 from rdb$database
>
> resulting in:
>
31 matches
Mail list logo
