One thing we don't introduce anywhere, which we probably should, is the idea of modelling problems with state machines.
In the computing cache project, it can be helpful to think of the state of any one key as "doesn't have value", "has value", or "value is being computed". Framing operations on the cache as "transitioning from doesn't have value to value is being computed" or "waiting for the transition from value is being computed to has value" can be really useful, particularly when thinking about what operations need to happen under the same lock (e.g. under the same lock you need to check that there currently is no value before you start computing a value), and helps to think about invalid states (e.g. it explains why you should put the newly-computed value in the cache before removing it from the pending queue, or do both under the same lock - to prevent an observable "value has been computed but isn't in the cache yet" state).
We don't talk about this anywhere. We probably want to.
I think this is generally a useful framing that could be put into the SDC.
It probably could go into ITP if we really wanted, if we extended the "state" section of ITP, but I think thinking about state at all is already a new concept and a lot to be working out in ITP...
But a lot of the motivation for this kind of framing is around concurrency, which we don't currently plan to cover in the SDC at all. So maybe we want to introduce this as a CYF+ topic until we work out which pieces best fit into the SDC...
It's been really interesting watching folks implementing the computing cache part of the CYF+ concurrency project.
One thing we don't introduce anywhere, which we probably should, is the idea of modelling problems with state machines.
In the computing cache project, it can be helpful to think of the state of any one key as "doesn't have value", "has value", or "value is being computed". Framing operations on the cache as "transitioning from doesn't have value to value is being computed" or "waiting for the transition from value is being computed to has value" can be really useful, particularly when thinking about what operations need to happen under the same lock (e.g. under the same lock you need to check that there currently is no value before you start computing a value), and helps to think about invalid states (e.g. it explains why you should put the newly-computed value in the cache before removing it from the pending queue, or do both under the same lock - to prevent an observable "value has been computed but isn't in the cache yet" state).
We don't talk about this anywhere. We probably want to.
I think this is generally a useful framing that could be put into the SDC.
It probably could go into ITP if we really wanted, if we extended the "state" section of ITP, but I think thinking about state at all is already a new concept and a lot to be working out in ITP...
But a lot of the motivation for this kind of framing is around concurrency, which we don't currently plan to cover in the SDC at all. So maybe we want to introduce this as a CYF+ topic until we work out which pieces best fit into the SDC...