Skip to content
Snippets Groups Projects
Commit bd265364 authored by Peter J. Keleher's avatar Peter J. Keleher
Browse files

auto

parent f765b416
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 15 additions and 13 deletions
p6.md
+ 15
− 13
View file @ bd265364
# Project 6: Supporting High-level Abstractions From a Shared Log # Project 6: Supporting High-level Abstractions From a Shared Log
**v1.0**<br> **v1.1**<br>
**Due Dec 10** **Due Dec 10**
## Setup ## Setup
...@@ -25,9 +25,7 @@ KV. Like w/ Tango, we expect transactions to support strict ...@@ -25,9 +25,7 @@ KV. Like w/ Tango, we expect transactions to support strict
serializability. Writes from transactions that abort do not affect the serializability. Writes from transactions that abort do not affect the
KV. KV.
Finally, in the *tree* type, you will create a shared tree that Finally, you will build something else. See below.
supports concurrent modifications via simple mutations. You build this
entirely from scratch.
You will build your tango support in a new `p6/tango` module. Your You will build your tango support in a new `p6/tango` module. Your
applications will call the tango module API to access the shared log. applications will call the tango module API to access the shared log.
...@@ -162,6 +160,16 @@ non-transactional updates, but *calls for transactional updates are ...@@ -162,6 +160,16 @@ non-transactional updates, but *calls for transactional updates are
delayed until a transaction is known to have committed*. delayed until a transaction is known to have committed*.
## Something Else
Build some other distributed data type on tango. Or do something else cool w/ Raft.
## Points.
- [**40 pts**] intCRED
- [**60 pts**] transactional KV
- [**50%**] of final exam grade: "Something Else". The other 50% will be a take-home exam.
Everything, the "Something Else", should be well-documented in your README.
## Testing. ## Testing.
1. I will test by running two copies of `intCRDT.go` against "scriptInt.1" 1. I will test by running two copies of `intCRDT.go` against "scriptInt.1"
concurrently, multiple times. Each time the end result should be the concurrently, multiple times. Each time the end result should be the
...@@ -170,16 +178,10 @@ same regardless of interleaving. ...@@ -170,16 +178,10 @@ same regardless of interleaving.
"scriptKV.1" with one app. As the third READ is seen, I will start "scriptKV.1" with one app. As the third READ is seen, I will start
another instance of `kv.go` running "scriptKV.2", which should another instance of `kv.go` running "scriptKV.2", which should
cause transaction 2 to abort. Transactions 1 and 3 will commit. cause transaction 2 to abort. Transactions 1 and 3 will commit.
3. You should come up scripts, similar to the KV scripts, to test your 3. Your something else should come w/ scripts, similar to the KV scripts, for testing. Details should be in your README.md file.
log-based tree implementation. Details should be in your README.md file.
## Random Details
- The tree should support mutations such as:
- add a child
- move a child
- delete a child
Transactional semantics allow these to be combined atomically.
## Submitting ## Submitting
Submit by pushing to your repository. Submit by pushing to your repository.
- DO update the `README.md` to - DO update the `README.md` to
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment