NO

Recent Posts

Pages: [1] 2 3 ... 10
1
Bug reports / Bug list
« Last post by TimoVJL on Today at 12:50:33 pm »
Some bugs:

compiler Inlining option -Ob0 doesn't always work?

double conversion last bit problem:
 floating point number from string conversion errors in source code.
 problem with strtod, what comes from crt function __fppow10
https://forum.pellesc.de/index.php?topic=4322.msg16031#msg16031
https://forum.pellesc.de/index.php?topic=4322.msg16091#msg16091

https://forum.pellesc.de/index.php?topic=7124.msg27041#msg27041
https://forum.pellesc.de/index.php?topic=7124.msg27044#msg27044

I update a this list later...
2
Expert questions / Re: atomic pointer types...
« Last post by Chris M. Thomasson on April 23, 2018, 11:31:04 pm »
Chris sorry for the delay in answer.
It is very clear that atomic access to large memory areas nowadays can be efficiently performed on the majority of available architectures.
The PellesC compiler seems to handle only a minor subset of them, only basic data types and the void pointer. This kind of implementation doesn't need to analyze the object, and its size, to define if it can be implemented in a lock-free fashion.
Such approach keep things simple maybe as first implementation.
I can't say if in a future release there will be in-compiler support for lock-free atomic structures, only Pelle can decide.

Great for a first implementation! I am crossing my fingers that a future release will allow atomic POD structures that contain data such that the size of the said structure equals the size of two pointers. That ability alone allows for a much richer realm of algorithms to be implemented...

Thank you.  :)
3
Hello aardvajk,

I am still in contact with Pelle and he tries to release a new version this year. Pelles C is not dead, just a bit in a snail pace.

Best regards
4
Bug reports / Re: Loosing files (once in a great while)
« Last post by frankie on April 18, 2018, 05:30:15 pm »
but also I'm hoping that it doesn't happen.
Me too Daniel :D
5
Bug reports / Re: Loosing files (once in a great while)
« Last post by daniel_bingamon on April 18, 2018, 03:11:42 pm »
Frankie, actually I'm still using Windows 7.  This unit is 32-bit.
I've not had it happen on my computer at home which is win 7 64-bit but my frequency of use is a lot less at home.

If it shows I will get the information -- but also I'm hoping that it doesn't happen.
6
Expert questions / Re: atomic pointer types...
« Last post by frankie on April 18, 2018, 02:45:04 pm »
Chris sorry for the delay in answer.
It is very clear that atomic access to large memory areas nowadays can be efficiently performed on the majority of available architectures.
The PellesC compiler seems to handle only a minor subset of them, only basic data types and the void pointer. This kind of implementation doesn't need to analyze the object, and its size, to define if it can be implemented in a lock-free fashion.
Such approach keep things simple maybe as first implementation.
I can't say if in a future release there will be in-compiler support for lock-free atomic structures, only Pelle can decide.
7
Expert questions / Re: atomic pointer types...
« Last post by Chris M. Thomasson on April 14, 2018, 10:03:49 pm »
Ahhh! Thank you for the correction. I am getting true on two out of three ...
The output is:
Code: [Select]
atomic_is_lock_free(void*):true
atomic_is_lock_free(uintptr_t):true
atomic_is_lock_free(structure):false

On x86 the atom structure can be implemented with cmpxchg8b.

Still not sure why I am getting false for atomic_is_lock_free(&AtomStruct).
The atomic qualifier is supposed to assure that operations on the object are made atomically, substantially the whole object is modified or acquired integrally without contamination from concurrent accesses. This basically means that whatever object having correspondence with a processor atomic instruction is intrinsically atomic.
A structure is by default larger of CPU atomic instructions, then is intrinsically not free from lock. And this is the correct answer you get.
Anyway changing a member of the structure, that is one of the intrinsically atomic instructions of the CPU, will be executed in standard way. I.e. The following:
Code: [Select]
atomic_store(&AtomStruct.a, 1);Will be in X86-32bits:
Code: [Select]
  mov  eax,1
  xchg  dword ptr [AtomStruct],eax
I hope to have been clear.


Wrt to my DWCAS proxy collector, I need a pointer and an intptr_t to be at least lock-free.

Code: [Select]
struct ct_proxy_dwcas
{
    struct ct_proxy_node* node;
    intptr_t count;
};

We can do this in 32-bit systems with cmpxchg8b. We can do this in 64-bit systems with cmpxchg16b.

https://www.felixcloutier.com/x86/CMPXCHG8B:CMPXCHG16B.html

We can do this in IBM wrt the Principals of Operation for a lock-free stack and ABA counter:

http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr009.pdf

Take a look at Appendix A-50 Free Pool Manipulation.

Also, what about, 32-bit x86:
Code: [Select]

AC_SYS_APIEXPORT
int AC_CDECL
np_ac_i686_atomic_dwcas_fence
( void*,
  void*,
  const void* );


np_ac_i686_atomic_dwcas_fence PROC
  push esi
  push ebx
  mov esi, [esp + 16]
  mov eax, [esi]
  mov edx, [esi + 4]
  mov esi, [esp + 20]
  mov ebx, [esi]
  mov ecx, [esi + 4]
  mov esi, [esp + 12]
  lock cmpxchg8b qword ptr [esi]
  jne np_ac_i686_atomic_dwcas_fence_fail
  xor eax, eax
  pop ebx
  pop esi
  ret

np_ac_i686_atomic_dwcas_fence_fail:
  mov esi, [esp + 16]
  mov [esi + 0],  eax;
  mov [esi + 4],  edx;
  mov eax, 1
  pop ebx
  pop esi
  ret
np_ac_i686_atomic_dwcas_fence ENDP

Double Width Compare and Swap (DWCAS) should be on C11 and C++11 when the architecture supports it.

I know that C++11 totally supports lock-free DWCAS on architectures that provide it, works like a charm. Read:

https://groups.google.com/forum/#!original/lock-free/X3fuuXknQF0/Ho0H1iJgmrQJ

Why is atomic_is_lock_free wrt a pointer to a double width structure giving me false, when it totally works lock-free on the architecture itself?
8
Expert questions / Re: atomic pointer types...
« Last post by frankie on April 14, 2018, 05:05:20 pm »
Ahhh! Thank you for the correction. I am getting true on two out of three ...
The output is:
Code: [Select]
atomic_is_lock_free(void*):true
atomic_is_lock_free(uintptr_t):true
atomic_is_lock_free(structure):false

On x86 the atom structure can be implemented with cmpxchg8b.

Still not sure why I am getting false for atomic_is_lock_free(&AtomStruct).
The atomic qualifier is supposed to assure that operations on the object are made atomically, substantially the whole object is modified or acquired integrally without contamination from concurrent accesses. This basically means that whatever object having correspondence with a processor atomic instruction is intrinsically atomic.
A structure is by default larger of CPU atomic instructions, then is intrinsically not free from lock. And this is the correct answer you get.
Anyway changing a member of the structure, that is one of the intrinsically atomic instructions of the CPU, will be executed in standard way. I.e. The following:
Code: [Select]
atomic_store(&AtomStruct.a, 1);Will be in X86-32bits:
Code: [Select]
  mov  eax,1
  xchg  dword ptr [AtomStruct],eax
I hope to have been clear.
9
Expert questions / Re: atomic pointer types...
« Last post by Chris M. Thomasson on April 13, 2018, 10:58:05 pm »
Ahhh! Thank you for the correction. I am getting true on two out of three, I used your struct atom example:

Code: [Select]
#include <stdio.h>
#include <stdint.h>
#include <stdatomic.h>

int main(void)
{
    void* _Atomic ptr = NULL;

    printf("atomic_is_lock_free(void*):%s\n",
           atomic_is_lock_free(&ptr) ? "true" : "false");

    uintptr_t _Atomic uptr = 0;

    printf("atomic_is_lock_free(uintptr_t):%s\n",
           atomic_is_lock_free(&uptr) ? "true" : "false");

    _Atomic struct atom {int a; int b;};    //Make compiler happy and break declaration. See note below
    struct atom AtomStruct = {0};

    printf("atomic_is_lock_free(structure):%s\n",
atomic_is_lock_free(&AtomStruct) ? "true" : "false");

    return 0;
}

The output is:
Code: [Select]
atomic_is_lock_free(void*):true
atomic_is_lock_free(uintptr_t):true
atomic_is_lock_free(structure):false

On x86 the atom structure can be implemented with cmpxchg8b.

Still not sure why I am getting false for atomic_is_lock_free(&AtomStruct).

Well, at least the void pointer is atomic now. Thank you for the feedback. :^)

Fwiw, I need something like structure to be at least lock free:

Code: [Select]
struct ct_dwcas
{
   intptr_t count;
   void* node;
};

Want to build my simple proxy collector using this compiler. Here is a link to working C++11 code:

https://groups.google.com/d/topic/comp.lang.c++/B9Phyf-6N00/discussion

There is a way to hack it, using a proxy algo of mine that does not need double width compare-and-swap (DWCAS).

https://groups.google.com/d/msg/lock-free/X3fuuXknQF0/0VF_u-7shrsJ
10
Tips & tricks / Re: WinFile
« Last post by Vortex on April 13, 2018, 08:15:06 pm »
Hi Timo,

Thanks, nice work.
Pages: [1] 2 3 ... 10