5 ms·

You need to implement some form of GC when you want to free memory in a lock-free container. Read the thread and the employee's statements from Intel: https://c

by pebal 4y ago

You need to implement some form of GC when you want to free memory in a lock-free container. Read the thread and the employee's statements from Intel: https://community.intel.com/t5/Intel-oneAPI-Threading-Building/Concurrent-stack/td-p/900745 https://community.intel.com/t5/Intel-oneAPI-Threading-Buildi... New processors use 56 bits of virtual address. It doesn't matter if you have that much memory, because addresses are virtual. Also, newer versions of Android do not allow the use of unused address bits.

CyberDildonics 4y ago
You need to implement some form of GC when you want to free memory in a lock-free container. This is again, your assertion, it isn't evidence or an explanation of any kind, you just keep saying the same thing. The link you have is people discussing a bunch of surrounding issues. Fundamentally, allocation of arbitrary memory just doesn't have to be ingrained in the lock free data structure. As soon as you can deal with 64 bits at a time, you can store pointers. There are lock free heap allocators and lock free block allocators that can be combined with whatever you are using to deal lock free with integers/pointers. Freeing memory is going to be a matter of ownership. If you pop a pointer, that thread should own it. Not only that, but a pointer combined with a reference count can always be used if necessary and again, 128 bit compare and swap has been around for 20 years.
- pebal 4y ago
  In the link I pointed you have an example given and an explanation of why you need to have specific memory management for concurrent containers. It cannot be explained any clearer.
  - CyberDildonics 4y ago
    I've given you a lot of detailed explanations you haven't actually explained anything. I didn't see what you're talking about in the 15 year old message board discussion and I think if there was something specific and clear you would have copied and pasted it. I also think that if you had any understanding of what you're saying, you would have given an explanation yourself. So go ahead and actually put something here that you can back up. It is a common scenario where someone has no real evidence to link something adjacent and then tell someone to 'go find it in this link'.
    - deleted 4y ago
      [deleted]
    - deleted 4y ago
      [deleted]
    - deleted 4y ago
      [deleted]
    - pebal 4y ago
      From the document you linked: int lfstack_pop(_Atomic lfstack_t \*lfstack) { lfstack_t next; lfstack_t orig = atomic_load(lfstack); do { if (orig.head == NULL) // undefined behavior !!! { return -1; } next.head = orig.head->next; } while (!atomic_compare_exchange_weak(lfstack,&orig,next)); free(orig.head); return 0; } If the first thread is preempted before the if(...) is executed, and then the second thread executes the entire method, then you will use data after freeing when the first thread resumes. Consider why the boost container doesn't free memory.
      - CyberDildonics 4y ago
        I asked you about the specific of what you were trying to point out in your own link to the 15 year old message board and instead of answering that you moved on to something else. Can you focus and nail down one claim with specifics before moving on to something else?
        pebal 4y ago
        A similar example is posted there, just read it. It's best to read about the problems of concurrent containers, because you clearly don't understand the topic.
        CyberDildonics 4y ago
        If it's so similar, then copy and paste it or at least link directly to it. If you understand these things so well, why can't you explain them? Everything you are doing is the classic playbook of someone who can't really back up what they're saying. There is the 'I already gave evidence' phase and at some point the 'I would totally give real evidence, but I don't like the way you're asking' phase. I've already done all the things you claim are impossible. That's how I know what you're saying is nonsense. Avoiding a double free on a pointer can always be done with atomic reference counting so that only one thread claims ownership. That's the whole story. You haven't given a shred of evidence to explain what garbage collection enables something that was previously impossible. It is obvious that if you had something you could say that directly applies to what you claimed before (some algorithms can't be done without garbage collection), that you would have already said it a long time ago.

by pebal 4y ago

CyberDildonics 4y ago

You need to implement some form of GC when you want to free memory in a lock-free container. This is again, your assertion, it isn't evidence or an explanation of any kind, you just keep saying the same thing. The link you have is people discussing a bunch of surrounding issues. Fundamentally, allocation of arbitrary memory just doesn't have to be ingrained in the lock free data structure. As soon as you can deal with 64 bits at a time, you can store pointers. There are lock free heap allocators and lock free block allocators that can be combined with whatever you are using to deal lock free with integers/pointers. Freeing memory is going to be a matter of ownership. If you pop a pointer, that thread should own it. Not only that, but a pointer combined with a reference count can always be used if necessary and again, 128 bit compare and swap has been around for 20 years.

pebal 4y ago
In the link I pointed you have an example given and an explanation of why you need to have specific memory management for concurrent containers. It cannot be explained any clearer.
- CyberDildonics 4y ago
  I've given you a lot of detailed explanations you haven't actually explained anything. I didn't see what you're talking about in the 15 year old message board discussion and I think if there was something specific and clear you would have copied and pasted it. I also think that if you had any understanding of what you're saying, you would have given an explanation yourself. So go ahead and actually put something here that you can back up. It is a common scenario where someone has no real evidence to link something adjacent and then tell someone to 'go find it in this link'.
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - pebal 4y ago
    From the document you linked: int lfstack_pop(_Atomic lfstack_t \*lfstack) { lfstack_t next; lfstack_t orig = atomic_load(lfstack); do { if (orig.head == NULL) // undefined behavior !!! { return -1; } next.head = orig.head->next; } while (!atomic_compare_exchange_weak(lfstack,&orig,next)); free(orig.head); return 0; } If the first thread is preempted before the if(...) is executed, and then the second thread executes the entire method, then you will use data after freeing when the first thread resumes. Consider why the boost container doesn't free memory.
    - CyberDildonics 4y ago
      I asked you about the specific of what you were trying to point out in your own link to the 15 year old message board and instead of answering that you moved on to something else. Can you focus and nail down one claim with specifics before moving on to something else?
      - pebal 4y ago
        A similar example is posted there, just read it. It's best to read about the problems of concurrent containers, because you clearly don't understand the topic.
        CyberDildonics 4y ago
        If it's so similar, then copy and paste it or at least link directly to it. If you understand these things so well, why can't you explain them? Everything you are doing is the classic playbook of someone who can't really back up what they're saying. There is the 'I already gave evidence' phase and at some point the 'I would totally give real evidence, but I don't like the way you're asking' phase. I've already done all the things you claim are impossible. That's how I know what you're saying is nonsense. Avoiding a double free on a pointer can always be done with atomic reference counting so that only one thread claims ownership. That's the whole story. You haven't given a shred of evidence to explain what garbage collection enables something that was previously impossible. It is obvious that if you had something you could say that directly applies to what you claimed before (some algorithms can't be done without garbage collection), that you would have already said it a long time ago.