[mwcampbell]

> Don't try to avoid synchronization primitives, or even invent your own.

Makes me wonder if it's really a good idea in most cases to use, for example, the Rust parking_lot crate, which reimplements mutexes and RW locks. Besides the speed boost for uncontended RW locks, particularly on x64 Linux, what I really like about parking_lot is that a write lock can be downgraded to a read lock without letting go of the lock. But maybe I'd be better off sticking with the tried-and-true OS-provided lock implementations and finding another way to work around the lack of a downgrade option.

[cesarb]

Unless you're the maintainer of the parking_lot crate, you're not "inventing your own". And since parking_lot is AFAIK the second most popular implementation of mutexes and RW locks in Rust (the most popular one being obviously the one in the Rust standard library, which wraps the OS-provided lock implementations), you can assume it's well tested.

[codeflo]

Everything about which people tell you to “not invent your own” must be invented by someone.

[twodai]

I guess it's more about priorities, if you want to build a web app don't reinvent the underlying protocols. If you want to build an embedded system for monitoring room temperature don't invent your own locks.

But if you want to make a lock by all means make a lock, just don't go and reinvent the chip architecture...

[pornel]

You're taking a saying too literally.

People who take on task of writing such library, and develop it to the point it's a language-wide standard, usually know what they're doing (or learn on the job :)

Popularity of such library helps test it thoroughly on many platforms in various conditions, so there's a high chance the bugs will be spotted and fixed.

[oriki]

I mean, that's too literal of an interpretation.

It's more like "if you don't need to, don't invent your own [x]." People who like to invent [x] are usually smart enough to understand why that warning is there to begin with, and don't tend to argue with it.

[JulianMorrison]

It's not "don't invent it".

It's "be competent before you invent it, because it's hard". And if you aren't, then let someone who is do the inventing.

[convolvatron]

the best way to _get_ competent is to try

so yes - invent your own synchronization primitives. please.

just dont believe they are correct without being serious about trying to prove they are. and dont hold up your whole project for self-enrichment.

but try to layer as much in as you can.

developers these days are so productive, until they fall down and cant get up. and then they are completely useless.

[JulianMorrison]

Disagreed. There are some problems, and low level hardware is one of them, where you need understanding and not just experience.

[convolvatron]

so what would qualify one to do this kind of work? a graduate class in parallel programming?

[gpderetta]

Don't invent anything unless your job is to invent it. Of course you might not know what your job is until you are in the middle of it.

[api]

In that case you should never run any software. Go live as a hunter-gatherer in the wilderness.