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

50 years later, is two-phase locking the best we can do?

concurrencyfreaks.blogspot.com

Post reply on HN
Print view View original

61–70 of 87 posts

Re: 50 years later, is two-phase locking the best we can do?

#61

Post by telez »

colanderman wrote: post #49
telez wrote: post #42

Earlier quoted context omitted.

the chart doesn't seem visible on ios safari but i can see it on firefox desktop however, the figure seems to be the same as from the linked paper: https://zenodo.org/record/7886718

Ah ok I found it there, I see what you mean now. My only guess would be cache effects? With that large AVL tree (1 M entries, so likely dozens of MiB), you are escaping L2 cache and hitting shared L3 or main memory for a large portion of lookups, and are bandwidth-constrained at the die level, thus adding that knee (which I think is visible with some of the other algorithms as well).

but TL2 shouldn't be using more memory than say TinySTM, i don't think. If the implementations are object based and nodes are cache aligned, adding an extra 8 bytes for the versioned-lock shouldn't bump the node size to greater than a cache line.

however, i do think the tl2 implementation as described in the paper is memory based, as is TinySTM so every read needs to do a hash to locate the corresponding lock / meta data. the read-only transactions for tl2 and TinySTM seem identical to me which is why i am so confused.

looking at other figures from the 2PLSF paper, the TL2 for 100% lookup on hash set and skip list it looks like such a dog compared to the other algos.

Re: 50 years later, is two-phase locking the best we can do?

#62

Post by ris »

samsquire wrote: post #35

I'm a beginner in this topic and I find this topic interesting. I really want there to be an easy-to-deploy consistency solution. If I have a distributed microservice architecture and I want to keep multiple datastores in synchronization or "consistent" what's the industry best practice? A few days ago I was trying to solve the inconsistency problem with "settled timestamps" which is a kind of multiversioning idea ex…

> If I have a distributed microservice architecture and I want to keep multiple datastores in synchronization or "consistent" what's the industry best practice?

Not to use a distributed microservice architecture.

Re: 50 years later, is two-phase locking the best we can do?

#63

Post by ncruces »

klabb3 wrote: post #21

One thing I didn’t quite catch was: I thought most write transactions needs consistent reads on many (contended) “objects”, but the actual writes are often just one or two objects. Is 2PL addressing this or does a write transaction take write locks on all objects?

You take either read OR write locks for whatever you need, and keep all locks until you commit the transaction.

That (possibly brief) moment where you hold all the necessary locks is your point of linearizability: it's as if everything happened at that exact moment.

Re: 50 years later, is two-phase locking the best we can do?

#66

Post by PhilipRoman »

wyuenho wrote: post #64

We seriously need to have a new HN policy that requires every link posted to be HTTPS link

Why? There are plenty of older useful sites which work just fine over HTTP. If you mean for cases where https is supported, but link is http - I agree.

Re: 50 years later, is two-phase locking the best we can do?

#67

Post by MaxBarraclough »

PhilipRoman wrote: post #66
wyuenho wrote: post #64

We seriously need to have a new HN policy that requires every link posted to be HTTPS link

Why? There are plenty of older useful sites which work just fine over HTTP. If you mean for cases where https is supported, but link is http - I agree.

There are plenty of good reasons to use HTTPS. [0]

It doesn't make sense to link to HTTP when the site works fine over HTTPS, which is the case here. I'm not sure I'd want to completely ban all HTTP though.

[0] https://news.ycombinator.com/item?id=27507886

Re: 50 years later, is two-phase locking the best we can do?

#68

Post by rawgabbit »

zaphirplane wrote: post #37
rawgabbit wrote: post #25

Earlier quoted context omitted.

You can take locks on all objects before you write. Most systems don’t do that. Usually there are multiple writes to complete a business process. In each step stale data is read to create a write request similar to how you place your order with the wait staff at the restaurant. The wait staff will orchestrate your request. First the chef prepares your meal according to the order ticket. Second the wait staff delivers…

IIUC, That’s a micro service way, missing cancellations and rollback and timeouts What happens if the chef can’t fulfill the meal, the customer leaves cause the order is taking long … etc Most real life will not charge the customer is the chef can’t make the meal and cancel the cooking if the customer leaves The analogy maybe going far ;)

True. If the customer leaves in mid process, we would have to issue a reversal transaction. Eat the financial loss, dispose of the food, and void the order the ticket.

Re: 50 years later, is two-phase locking the best we can do?

#69

Post by appplication »

wyuenho wrote: post #64

We seriously need to have a new HN policy that requires every link posted to be HTTPS link

Honest question: what is the consequence of visiting an HTTP link rather than HTTPS for a site where my interaction is read only? Is there some security issue? Or is it privacy concerns.

Re: 50 years later, is two-phase locking the best we can do?

#70

Post by uobytx2 »

appplication wrote: post #69
wyuenho wrote: post #64

We seriously need to have a new HN policy that requires every link posted to be HTTPS link

Honest question: what is the consequence of visiting an HTTP link rather than HTTPS for a site where my interaction is read only? Is there some security issue? Or is it privacy concerns.

There is a security issue and a privacy issue.

The privacy issue is that your local WiFi provider, direct isp, and all the intermediate isps can see not only which site you visit, but all your activity within that site (like which pages you visit or things you download).

The security part is that any of those who can view can also do a “man in the middle” attack. Comcast could decide to send you a different version of the website that was more favorable to their company, or inject ads (ISPs have been known to inject ads on sites they don’t own before https was big).

A hacker could send you a version that gets you to download malware by replacing content or links. They can see and effect everything you do and see in such a site if they can intercept your request.

Post reply on HN