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

DiceDB

dicedb.io

Post reply on HN
Print view View original

131–140 of 143 posts

Re: DiceDB

#131

Post by nebulous1 »

kiitos wrote: post #130
nebulous1 wrote: post #119

Earlier quoted context omitted.

I don't use Go. https://go.dev/ref/mem If I'm reading this correctly, they are recommending a lock in this situation. However, they are saying the implementations has two options, either raise an error reporting the race (if the implementation is told to do so), or, because the value being read is not larger than a machine word, reply to the read with a correct value from a previous write. If true then it cannot repl…

> However, they are saying the implementations has two options, either raise an error reporting the race (if the implementation is told to do so), or, because the value being read is not larger than a machine word, reply to the read with a correct value from a previous write. The spec says > A read r of a memory location x holding a value that is not larger than a machine word must observe some write w such that r do…

Thanks. So the structure in the OP is an array of uint32s.

> that unsynchronized reads of a uint64 will return some previous valid write, it doesn't guarantee anything about which value is returned

Your the second person saying this, so is my interpretation that this is dissallowed by the part that you quoted incorrect?

> must observe some write w such that r does not happen before w and there is no write w' such that w happens before w' and w' happens before r

edit: somebody is answering this below by the way

Re: DiceDB

#132

Post by nebulous1 »

fashion-at-cost wrote: post #129
nebulous1 wrote: post #128

Earlier quoted context omitted.

I don't disagree, but that's not the claim I was replying to. The question I was asking about was > I understand the need for correct lock-free impls: Given OP's description, simply avoiding read mutexes can't be the way to go about it? I did note that the documentation recommends a lock. > read the first value ever set to the variable for the entire lifetime of the program That is not my reading of the current memor…

In this context, ”happens before” is not a wall-clock colloquialism but in fact a term of art that is specifically described as: > The happens before relation is defined as the transitive closure of the union of the sequenced before and synchronized before relations. Without synchronization, the degenerate sequencing is perfectly valid. That’s the problem with being “clever” - you miss a definition and your entire me…

So, in the situation in the comment OP, with sychronized writes and and unsynchronized reads, what is this "happens before" stipulation prohibiting?

Re: DiceDB

#133

Post by fashion-at-cost »

nebulous1 wrote: post #132
fashion-at-cost wrote: post #129

Earlier quoted context omitted.

In this context, ”happens before” is not a wall-clock colloquialism but in fact a term of art that is specifically described as: > The happens before relation is defined as the transitive closure of the union of the sequenced before and synchronized before relations. Without synchronization, the degenerate sequencing is perfectly valid. That’s the problem with being “clever” - you miss a definition and your entire me…

So, in the situation in the comment OP, with sychronized writes and and unsynchronized reads, what is this "happens before" stipulation prohibiting?

A single reader thread cannot read a value written by a write, then later read a value written by a write that happens before the first write.

Re: DiceDB

#134

Post by nebulous1 »

fashion-at-cost wrote: post #133
nebulous1 wrote: post #132

Earlier quoted context omitted.

So, in the situation in the comment OP, with sychronized writes and and unsynchronized reads, what is this "happens before" stipulation prohibiting?

A single reader thread cannot read a value written by a write, then later read a value written by a write that happens before the first write.

Thanks!

Re: DiceDB

#135

Post by kiitos »

senderista wrote: post #126
ignoramous wrote: post #103

Earlier quoted context omitted.

> single-writer lock-free algorithm I understand the need for correct lock-free impls: Given OP's description, simply avoiding read mutexes can't be the way to go about it?

Oh, so cycleMap is a non-threadsafe structure? I don't know golang so I didn't realize this.

Nothing in Go is thread-safe, unless explicitly documented otherwise. Some examples of explicitly-documented-otherwise stuff are in package sync and package sync/atomic.

cycleMap is definitely not thread-safe. The authors knew this, to some extent, because they synchronized writes via an adjacent mutex. But they didn't synchronize reads thru the same mutex, which is the issue.

Re: DiceDB

#137

Post by senderista »

kiitos wrote: post #135
senderista wrote: post #126

Earlier quoted context omitted.

Oh, so cycleMap is a non-threadsafe structure? I don't know golang so I didn't realize this.

Nothing in Go is thread-safe, unless explicitly documented otherwise. Some examples of explicitly-documented-otherwise stuff are in package sync and package sync/atomic. cycleMap is definitely not thread-safe. The authors knew this, to some extent, because they synchronized writes via an adjacent mutex. But they didn't synchronize reads thru the same mutex, which is the issue.

OK, this doesn't inspire confidence then.

Re: DiceDB

#138

Post by BoorishBears »

graynk wrote: post #115
BoorishBears wrote: post #109

Earlier quoted context omitted.

Yeah, and I'm sure someone clicked it thinking it was a DB for EA's Dice Studios. If you expose something to enough people you'll get some unreasonable takes and interpretations of it. It's important to ignore them.

> If you expose something to enough people you'll get some unreasonable takes and interpretations of it. It's important to ignore them. Quite literally the main function of dice is to give you random numbers. Looking over the website and readme I could not surmise why they would call it DiceDB except for "it sounds nice", but it's absolutely not unreasonable to look at the name and have a thought "it's probably a jok…

There are literal mountains of software named for no particular reason (let alone sounding nice), or named by origins no person would ever infer without digging in deeper.

Reasonable people realize this and won't discard a project as a joke because of such a teneous connection, and the fact they've gotten traction is a testament to that.

Re: DiceDB

#139

Post by jorangreef »

hp77 wrote: post #58
ac130kz wrote: post #54

Earlier quoted context omitted.

IO multithreading is still not fully there, there were significant improvements within the first couple of iterations, hopefully, it will improve further. I see that Dragonfly uses iouring, which is not recommended by Google due to security vulnerabilities.

I read Google is limitting the use of io_uring, but I have seen io_uring being used in other Databases, TigerBeetle is another DB which uses io_uring.

Joran from TigerBeetle here.

Yes, per [1] Google did restrict their use of io_uring on “production servers“, and in Android, ChromeOS etc.

However, within that same post, and what is often missed when that post is quoted, is that Google wrote that they did in fact “consider [io_uring] safe” for use by trusted components:

> For these reasons, we currently consider it safe only for use by trusted components.

A database like TigerBeetle is typically deployed in a trusted environment, and is such a trusted component.

[1] https://security.googleblog.com/2023/06/learnings-from-kctf-...

Re: DiceDB

#140

Post by graynk »

BoorishBears wrote: post #138
graynk wrote: post #115

Earlier quoted context omitted.

> If you expose something to enough people you'll get some unreasonable takes and interpretations of it. It's important to ignore them. Quite literally the main function of dice is to give you random numbers. Looking over the website and readme I could not surmise why they would call it DiceDB except for "it sounds nice", but it's absolutely not unreasonable to look at the name and have a thought "it's probably a jok…

There are literal mountains of software named for no particular reason (let alone sounding nice), or named by origins no person would ever infer without digging in deeper. Reasonable people realize this and won't discard a project as a joke because of such a teneous connection, and the fact they've gotten traction is a testament to that.

> Reasonable people realize this and won't discard a project as a joke

I agree. Nobody said anything about discarding nothing though. Only that it's a reasonable first thought to have upon hearing the name. And it is.

Post reply on HN