I do like that the article touches exactly this, and even though I'm a stranger to the entire concept, it makes sense:

>Hardly anyone hitchhikes any more, which is a shame because it encourages the habit of generosity from drivers, and it nurtures the grace of gratitude and patience of being kinded from hikers

I can see how it becomes a healthy feedback loop

that’s the submitters‘ user name, not the submission date

There's an inherent trade-off in everything

Besides, in this case.. it does not help that you'd also have to exchange hardware

I recall plenty of implementations turning into the same as a memory_order_acquire, which seems fine these days

> On all mainstream CPUs other than DEC Alpha, dependency ordering is automatic, no additional CPU instructions are issued for this synchronization mode, only certain compiler optimizations are affected (e.g. the compiler is prohibited from performing speculative loads on the objects that are involved in the dependency chain).

> Note that currently (2/2015) no known production compilers track dependency chains: consume operations are lifted to acquire operations.

https://en.cppreference.com/w/cpp/atomic/memory_order#Releas...

What if your young 'uns just do not... participate?

I am in a position where I am doing TL-level decisions, and try quite hard to demo, discuss, share the details and rationale. I write design proposals, documentation, do demo sessions, etc

But the information is just not flowing, and I notice how little the juniors participate in anything. And I don't exactly know what to put my finger on. It's probably some soft-skill I'm lacking, and that I do not know how to improve

But a part of me still feels that that perhaps the young 'uns are just... too fresh. Or that the approach is just too optimistic

This is where people management comes into play. It's really difficult to identify why someone isn't participating, until you get to know their work and personality. I have regular meetings with all the engineers to discuss their work, progress, what is holding them back, expectations for career, growth, stuff like that. It's impossible to completely separate tech leadership from people leadership.

In my experience, usually, lack of participation comes from a lack of self confidence in one's understanding of software development, and usually, finding something small and delegating ownership to a junior engineer, with some oversight, gets them to participate more. You have to let go of the notion of having something done perfectly and allow them to make their own mistakes, but don't let them make huge ones. This is the most common case. There are also people who don't care (can't do much here), or aren't very good technically.

> lack of participation comes from a lack of self confidence

Yep that's it... let's not have management or leadership take any responsibility. It's the subordinates fault of course.

Yes, all allocators (except perhaps OpenBSDs from what I see in this thread) do this. It is also why `calloc` exists - because zero-initializing every single allocation is really, really expensive.

I'm fairly confident that SQLite deals well with filesystem crashes nowadays, see https://www.sqlite.org/testing.html and https://www.sqlite.org/atomiccommit.html

>I'd never heard of the Robson bounds but they seem quite crucial to know about

I'd argue it's not really important in modern systems due to the use of virtual memory. With virtual memory, you can massive reduce fragmentation since you are no longer managing a single continuous region of memory.

Fragmentation still exists, but it only applies to "small" allocations (think smaller than a page) and in most scenarios it is a result of modern memory allocators preferring performance over reduced memory usage. Memory is cheap nowadays, and performance is king.

>Does anyone have some kind of list of the most important results in the area of memory management?

There is a survey [1] on the subject of memory allocation that mentions Robson's bounds and other results

[1] https://link.springer.com/chapter/10.1007/3-540-60368-9_19

Thanks!!

By "mobile" I'm guessing you mean laptops, and not phones.

Energy consumption of AMD's x86-64 CPUs are only impressive when comparing with Intel, they're not competitive with current ARM CPUs.

>It's applicable to C because most realistic implementations of malloc(3) store the size of the malloc'd area to the nearest word[2]

This is not so true anymore, and I'd be very careful with that sort of tricks. While the default memory allocator on most distributions (ptmalloc2) still probably works like that, there are other memory allocators in use like jemalloc/tcmalloc, which store metadata for a group of blocks (e.g all equal-sized blocks in a page) rather than for every single block.

Like Asooka wrote, you can malloc_usable_size(), if available. But have in mind that malloc_usable_size() returns the size of the block that malloc has given you, which can be _larger_ than the size you requested, as many memory allocators round block sizes up.

I actually wrote a memory allocator that works that way: https://github.com/ricleite/lrmalloc