Home » forums » LtU Forum

Modelling Actors with Locks

It appears that too many developers do not understand actors, and that actors have not been explained very well. My thought is that a model that behaves, to a degree, like actors might go a long way to explaining actors through analogy, especially if that model can be implemented with a minimum of code. Mind, the model is only an approximation. But even so, you may find it interesting/informative.

more

By laforge49 at 2014-04-08 11:45 | LtU Forum | previous forum topic | next forum topic | other blogs | 2297 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

holy reconciliation batman

the only thing i just remembered is that the banking example begs lots of comments like this one right here that pedantically point out that real banks do not do thing synchronously or with locks very much, it is all about the midnight (in some time zone) book reconciliation across all the banks :-)

By raould at Tue, 2014-04-08 17:43 | login or register to post comments

Try telling this to any

Try telling this to any systems professor besides Eric Brewer and their head will explore. Eventual consistency is the rule in the banking industry.

By Sean McDirmid at Wed, 2014-04-09 00:12 | login or register to post comments

Eventual consistency is the rule in the banking industry.

Since long before computers.

By Thomas Lord at Wed, 2014-04-09 00:55 | login or register to post comments

Ya, atomicity was

Ya, atomicity was really hard to implement with sailing vessels.

By Sean McDirmid at Wed, 2014-04-09 01:06 | login or register to post comments

Banking industry does realize eventual consistency

The banking industry does not realize eventual consistency. Banks always reserve the right to go back and reverse, e.g., cases of fraud.

By Hewitt at Wed, 2014-04-09 14:30 | login or register to post comments

re: The banking industry does not realize eventual consistency

Uh.. Yes it does.

Banks always reserve the right to go back and reverse, e.g., cases of fraud.

Banks unwind completed but fraudulent transactions by creating new transactions.

The exogenous determination that a fraud has occurred creates new assets and liabilities that get added to the books.

Transfers to settle those between institutions are cleared by the same eventually consistent system as the original transactions.

By Thomas Lord at Wed, 2014-04-09 16:23 | login or register to post comments

Exactly when is eventual consistency realized?

Exactly when is eventual consistency realized? At every point, there are outstanding problems and new problems can always pop to disturb previous deposits and withdrawals.

By Hewitt at Thu, 2014-04-10 01:04 | login or register to post comments

when is eventual consistency realized?

when is eventual consistency realized?

Whenever any set of extant transactions has been reconciled.

At every point, there are outstanding problems and new problems

Uh... "outstanding problems" and "new problems" are vague terms you have made up that don't really mean anything in this context.

can always pop to disturb previous deposits and withdrawals.

In real life banks process transactions. Each transaction is of a specific type, drawn from a short list. There are various exogenously imposed rules that determine how transactions are to be processed, including various time limits on their processing.

Earlier you expressed a confused understanding of how late detection of fraudulent transactions are handled. I'll repeat myself to say that past, reconciled transactions remain on the books -- consistently handled as ever they were. The detection of fraud can, in some circumstances, authorize the creation of brand new banking transactions.

Those new transactions do not mean that earlier transactions did not reach an eventually consistent reconciliation. It means only that there are new transactions.

By Thomas Lord at Thu, 2014-04-10 02:26 | login or register to post comments

No mythical "eventual" consistency because no consistency

In a large information system, consistency is never realized (much less "eventual" consistency, which has no precision).

A previous (large) deposit can in practice always be found to be contradictory with law and/or policy. Also, there are always a large number of contradictions on the books.

See LtU topic: Detected contradictions in large information systems

By Hewitt at Thu, 2014-04-10 20:30 | login or register to post comments

meta hewitt

A previous (large) deposit can in practice always be found to be contradictory with law and/or policy.

I'm not going to repeat myself a third time.

I resent the feeling that I've wasted time generously trying to converse with someone who so consistently acts like a brick wall.

Please do not engage me further on LtU.

By Thomas Lord at Fri, 2014-04-11 01:03 | login or register to post comments

Adding excuses does not magically erase contradictions

Adding excuses (e.g. supplementary "transactions") does not magically erase contradictions.

By Hewitt at Fri, 2014-04-11 15:46 | login or register to post comments

"Eventual consistency" is reconciliation and not consistency

"Eventual consistency" is a reconciliation model that trivially provides that if a sufficient times passes after a given data item is updated then all will read the same value.

Of course, "eventual consistency" says nothing about the consistency of a whole information system.

By Hewitt at Fri, 2014-04-11 15:53 | login or register to post comments

Multiple Replies

Hewitt: Please avoid posting numerous replies in quick succession. This is a discussion forum, not Twitter. You're not restricted to one-thought == one-comment. Your current posting style fragments the discussion, making it hard to follow.

Others: My apologies for the meta-comment.

By BrandonBloom at Fri, 2014-04-11 23:14 | login or register to post comments

Clarifying issues is not easy on LtU

Clarifying issues is not easy on LtU. In some ways, the platform is very rigid (and difficult to improve because of its implementation). For example, accidental posts cannot be deleted :-(

My two posts addressed different issues that can be responded to independently. Respondents to the different issues could potentially generate their own trees of responses. I don't see how it would have helped to wait a day to post the second issue.

By Hewitt at Mon, 2014-04-14 06:21 | login or register to post comments

This is the kind of crap

This is the kind of crap that most CS professors spew to their students. They always motivate atomicity with the classic bank account balance example, without even hinting to their students that this kind of logic is never atomic in practice.

Banks always reserve the right to go back and reverse, e.g., cases of fraud.

If all transactions were atomic, fraud would never happen right? Except it still does, and anyways networks are not fast or available enough to make hard atomicity a requirement. Banks instead still rely on reconciliation of ledgers, just like they did in the 1600s, to ensure that the books are balanced at the end of the day.

By Sean McDirmid at Wed, 2014-04-09 23:45 | login or register to post comments

Say what?

If all transactions were atomic, fraud would never happen right?

Why would you think that? If someone deposits a check signed with my name and our banks are the same, money can be transferred atomically from my account to his, but if the check is forged, it's fraudulent no matter how atomic the transaction may be.

By johnwcowan at Sat, 2014-04-12 01:06 | login or register to post comments

I know, I was being

I know, I was being sarcastic. Sorry it didn't come out more obvious.

By Sean McDirmid at Sat, 2014-04-12 01:38 | login or register to post comments

Synchronously transferring between different banks: oxymoron

Synchronously transferring money between different banks is an oxymoron.

Below is an implementation of a simple account:

CreateEuroAccount.[startingBalance:Currency] ≡
  Actor with myBalance≔startingBalance◊ 
     implements Account using
       GetBalance[ ]→ myBalance;
       Deposit[anAmount]→  Void afterward myBalance≔myBalance+anAmount;   
       Withdraw[anAmount]→
         (amount > myBalance) ? True ⦂ Throw OverdrawnException[ ],
                                False ⦂ Void afterward myBalance≔myBalance–anAmount◊¶▮


Account ≡ Interface GetBalance[ ]↦ Currency,
                    Deposit[Currency]↦ Void,
                    Withdraw[Currency]↦ Void◊▮

By Hewitt at Tue, 2014-04-08 22:51 | login or register to post comments

Application programs: Don't use locks, threads, channels, etc.

Application programs should use simple message passing. They should not use locks, threads, channels for communication, etc.

By Hewitt at Tue, 2014-04-08 22:59 | login or register to post comments