4 ms·

To answer various questions people have asked and to make one or two notes of my own; 1. The current version of the library contains a profound design flaw - i

To answer various questions people have asked and to make one or two notes of my own; 1. The current version of the library contains a profound design flaw - it allocates memory. This is not viable in any way. The next release (which is very close to completion, but has been deferred for the last month due to a crisis project at work) does not. Regarding ConcurrencyKit, it is an excellent project, and I know Samy (I was involved in him getting his last job); he is an excellent programmer. He said to me about four years ago I needed to make a new release :-) 2. Regarding ABA and memory reclaimation. There is a comment noting that it is hard to find this information in the docs. I apologise. It is indeed not particularly explained. The docs were written with a view to a non-lock-free informed user wishing to use the API, so technical information regarding the internal implementation is lacking. In the current release ABA is resolved by the use of DCAS (limiting the library to ARM and Intel), and there is no memory reclaimation. In the next release, memory reclaimation has been implemented (removing the limit of ARM and Intel). I also implemented on ARM LL/SC versions of the algorithms, but these have been removed, because it's too hard to know which platforms they will or will not work on. ARM is still supported of course, but by using LL/SC to emulate CAS. 3. The blog, ah, yes. It's where I let off steam in the heat of frustration, which is off course not always pleasent - however, it's nice to vent. I am thinking of getting rid of it though, because it's not very professional. 4. The reason for a new github repo on each release, and the naming strategy, is to permit the concurrent use of multiple releases of the library. By allowing a new release to be used in parallel with old releases, existing code does not have to be modified. This minimizes work and risk. For minor releases and bug releases, where APIs do not change, a global search and replace will permit a full change to the new version. 5. Regarding frames. The site uses a number of third-party applications, such as a forum and a blog. These all emit HTML which assumes they are generating the whole page - they have a <HTML> tag in their output. Their output then has to exist in a frame. If I capture it and send it to a DIV, the DIV renders incorrectly. Finally, please note the forum (which is fairly new) needs to be upgraded to reduce spam attacks (I've been too busy to do so). Currently I see hundreds of attempts each day, by robots, to generate accounts and so it is impractical to continually scan the lists of requests to find any real requests. The forum does now offer a captch for this, and as soon as I get time (one or two weeks) I will upgrade to this.

dbattaglia 11y ago
Slightly OT... I just read your no-fee NYC blog post, so funny and true! NYC co-op rentals are the worst. Hope you found something decent.
bhouston 11y ago
> The reason for a new github repo on each release, and the naming strategy, is to permit the concurrent use of multiple releases of the library. By allowing a new release to be used in parallel with old releases, existing code does not have to be modified. This minimizes work and risk. For minor releases and bug releases, where APIs do not change, a global search and replace will permit a full change to the new version. You can just have multiple branches in a single github repo. :) That is what most people do.
- rr56 11y ago
  I wanted to ask you if tags on a mian dev branch, wouldn't be enough, but I guess the reason for branches is the ability to port back some changes etc.?
Blackthorn 11y ago
Hey, I just wanted to say -- I think your blog is great! Entertaining and a lot of it rings true. If you get rid of it, move it to some other place at least!
ehmmm 11y ago
1. The current version of the library contains a profound design flaw - it allocates memory. What do you mean by that?, or could you elaborate how will you design it to not allocate any heap memory?
- lfds-admin 11y ago
  The design of memory access behaviour is absolutely paramount in high performance software. Such software has a great deal of time and effort invested in the design to minimize memory accesses and, where they must occur, to make them cache friendly - for example, ensuring the buffer used for something being read from is allocated next to the buffer being used to write to, so they will both be covered by a single TLB lookup. This requires complete control over memory allocation. A library which not only makes its own allocations but even more staggeringly at run-time, is beyond the pale - absolutely unusable. The next release performs no memory allocation; all allocation is performed by the user and passed into the function calls as pointers to those allocations. Users can still of course perform run-time allocations if they wish, but now they can also fully pre-allocate, in ways which are memory access friendly given the work being performed by their software.

dbattaglia 11y ago

Slightly OT... I just read your no-fee NYC blog post, so funny and true! NYC co-op rentals are the worst. Hope you found something decent.

bhouston 11y ago

> The reason for a new github repo on each release, and the naming strategy, is to permit the concurrent use of multiple releases of the library. By allowing a new release to be used in parallel with old releases, existing code does not have to be modified. This minimizes work and risk. For minor releases and bug releases, where APIs do not change, a global search and replace will permit a full change to the new version. You can just have multiple branches in a single github repo. :) That is what most people do.

rr56 11y ago
I wanted to ask you if tags on a mian dev branch, wouldn't be enough, but I guess the reason for branches is the ability to port back some changes etc.?

Blackthorn 11y ago

Hey, I just wanted to say -- I think your blog is great! Entertaining and a lot of it rings true. If you get rid of it, move it to some other place at least!

ehmmm 11y ago

1. The current version of the library contains a profound design flaw - it allocates memory. What do you mean by that?, or could you elaborate how will you design it to not allocate any heap memory?

lfds-admin 11y ago
The design of memory access behaviour is absolutely paramount in high performance software. Such software has a great deal of time and effort invested in the design to minimize memory accesses and, where they must occur, to make them cache friendly - for example, ensuring the buffer used for something being read from is allocated next to the buffer being used to write to, so they will both be covered by a single TLB lookup. This requires complete control over memory allocation. A library which not only makes its own allocations but even more staggeringly at run-time, is beyond the pale - absolutely unusable. The next release performs no memory allocation; all allocation is performed by the user and passed into the function calls as pointers to those allocations. Users can still of course perform run-time allocations if they wish, but now they can also fully pre-allocate, in ways which are memory access friendly given the work being performed by their software.