Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

apple.github.io

Post reply on HN
Print view View original

21–30 of 38 posts

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#21

Post by whizzter »

menaerus wrote: post #12
whizzter wrote: post #11

Earlier quoted context omitted.

Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls). The main benefit is not having the cost of threads, f.ex. a default thread on Windo…

> Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls). In cooperative scheduling how is it possible to have two coroutines running concu…

You're thinking of older early coroutines or in singlethreaded runtimes (JS).

It's M:N threading, most logical threads/tasks are more lightweight than full OS threads, the logical ones should preferably behave cooperatively but they can be scheduled onto any number of real worker threads (usually these systems picks something like 2x worker threads compared to real CPU/Core count to manage some codepaths not being as well behaved).

Erlang and .NET(with Task/async) uses this model, iirc modern Java does this also (but hides it) and I'd be surprised if the modern async Rust or C++ variations didn't do this as well.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#22

Post by whizzter »

ddorian43 wrote: post #13
whizzter wrote: post #11

Earlier quoted context omitted.

Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls). The main benefit is not having the cost of threads, f.ex. a default thread on Windo…

> aren't reliable if an async/coroutines moves threads between calls Then just don't move them between threads and you're good with thread locals, no?

Iirc often the frameworks don't have worker affinity, anyhow environments like .NET has "AsyncLocal" to provide an aware alternative.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#23

Post by mgaunard »

d4ng wrote: post #19
mgaunard wrote: post #18

Earlier quoted context omitted.

yield to the event loop

So they're waiting.

not really, they yield to other event sources, which is the opposite of waiting (which blocks forward progress and is a violation of real-time guarantees)

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#24

Post by DSingularity »

mgaunard wrote: post #23
d4ng wrote: post #19

Earlier quoted context omitted.

So they're waiting.

not really, they yield to other event sources, which is the opposite of waiting (which blocks forward progress and is a violation of real-time guarantees)

I think these things can be equivalent. It all depends on the definition of wait.

The simple example can be x86 with monitor/mwait instructions. These will suspend a hardware thread until it can be awoken when the memory write happens to the monitored address. Nothing happens on that cpu thread in the meanwhile. Yet at the same time if things are being virtualized the higher authority exists and it can do something else with the CPU until the write. Same for OS type of event synchronization like Linux futex.

I would argue that the wait abstraction is more powerful. The alternative isn’t powerful enough to enable these kinds of “wake me when I can be useful again” behaviors.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#25

Post by spacechild1 »

mgaunard wrote: post #17
pjmlp wrote: post #3

This looks kind of outdated, especially since we are on C++23 as latest approved standard, and co-routines would be a better approach since C++20. Also how is the supposed Swift rewrite going on?

Coroutines aren't great, even C++26 is explicitly avoiding them for its foundational concurrency model. In any case a good concurrency library doesn't need more than C++14.

In my understanding, senders/receivers is a more generalized concurrency model, but it has been designed to play well with coroutines.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#26

Post by pjmlp »

mgaunard wrote: post #17
pjmlp wrote: post #3

This looks kind of outdated, especially since we are on C++23 as latest approved standard, and co-routines would be a better approach since C++20. Also how is the supposed Swift rewrite going on?

Coroutines aren't great, even C++26 is explicitly avoiding them for its foundational concurrency model. In any case a good concurrency library doesn't need more than C++14.

Is it? Senders/receivers is based on NVidias experience using them on CUDA.

Naturally I haven't followed them that much, given how far away C++26 is from being usable for portable code.

Compilers are finally getting good enough with C++20 support for updating the default version.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#27

Post by hiyfsch »

Rohansi wrote: post #7
hiyfsch wrote: post #5

Earlier quoted context omitted.

Just because coroutines exist doesn’t mean everything should use them for concurrency. Why would it be better? It’s pretty easy to set up threads in general.

Threads use more system resources than coroutines so it can be a big deal when you can potentially have thousands of them running.

Yeah I guess also depends on the problem space. For example, dedicated threads doing something versus a bunch of short-lived asynchronous tasks that need scheduling anyhow.

If a bunch of tasks need to be schedule best not to have to reinvent the wheel on that if possible.

If there’s longer running tasks the benefits probably are less noticeable.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#28

Post by Dave_Rosenthal »

khurs wrote: post #16

Why has FoundationDB not been professionalised? Better website, better docs, official GUI? Is Apple responsible for preventing its wider uptake? Or alternative databases stronger?

Great Q--it's weird that Apple, Snowflake, and the other big contributors have put essentially zero calories into documentation/website/etc.

There has been some movement lately, though. I'm not sure who exactly to thank, but "the community" created a new unofficial resource for getting going with FoundationDB: https://foundationdb.vercel.app/7.3/

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#29

Post by d4ng »

mgaunard wrote: post #23
d4ng wrote: post #19

Earlier quoted context omitted.

So they're waiting.

not really, they yield to other event sources, which is the opposite of waiting (which blocks forward progress and is a violation of real-time guarantees)

The actor itself can be said to be waiting. When it yields, the thread is then able to run another actor which was waiting on a message, and which then has a message on the queue.

Re: FoundationDB's Flow – Bringing Actor-Based Concurrency to C++11

#30

Post by khurs »

Dave_Rosenthal wrote: post #28
khurs wrote: post #16

Why has FoundationDB not been professionalised? Better website, better docs, official GUI? Is Apple responsible for preventing its wider uptake? Or alternative databases stronger?

Great Q--it's weird that Apple, Snowflake, and the other big contributors have put essentially zero calories into documentation/website/etc. There has been some movement lately, though. I'm not sure who exactly to thank, but "the community" created a new unofficial resource for getting going with FoundationDB: https://foundationdb.vercel.app/7.3/

Thanks for that link
Post reply on HN