Stabilize lock statement

[jclark]

Semantics of experimental implementation are described in #346. We need to decide how we want to do this in the spec. I think we should have semantics that more focused on providing a model for the programmer that is easy to understand and reason about and that does not expose implementation details.

I think it unlikely that the user will want semantics where the effects of multiple lock statements appear to be interleaved. Accordingly, I propose that the semantics be that outermost lock statements are not interleaved. All outermost lock blocks in the program execute in a single total order. Nested lock blocks do nothing. The effect is as if all lock statements execute under a single, global, recursive lock.

This is similar to "atomic sections", which are often provided by language interfaces to software transactional memory e.g. C++. But several kinds of implementation are possible:

1. naive implementation using a single, global, recursive lock
2. transactional memory
3. compile-time lock inference

For Ballerina, we could start with 1 and then do 3. Papers on 3 include:

• Cherem, S., Chilimbi, T. M., & Gulwani, S. (2008, June). Inferring locks for atomic sections. In PLDI (Vol. 8, pp. 304-315).
• McCloskey, B., Zhou, F., Gay, D., & Brewer, E. (2006, January). Autolocker: synchronization inference for atomic sections. In ACM Sigplan Notices (Vol. 41, No. 1, pp. 346-358). ACM.
• Hicks, M., Foster, J. S., & Pratikakis, P. (2006, June). Lock inference for atomic sections. In Proceedings of the First ACM SIGPLAN Workshop on Languages, Compilers, and Hardware Support for Transactional Computing.

We also need to decide on the keyword. Possibilities are:

• lock
• synchronized
• atomic

This also relates to the pure function idea #145. We might say that a pure function can access module-level variables only within a lock statement.

[sanjiva]

Ref keyword - we did consider all these options when doing this originally.

I prefer to keep lock given we've already used it and the others didn't seem to have any more clarity for the developer. I don't think that has changed.

[jclark]

I am OK with lock: it's a good fit for the semantics I've proposed.

I think atomic is not right for this semantics, since the statement is not executed atomically.

I would also be OK with synchronized. It is better on our familiarity design principle, but it is a harder, more computer-sciencey word.

[vinok88]

It's better to define the semantics related to object and record fields within lock blocks as well. AFAIR, it was not clear on following areas in the previous design,

• Should we allow a parallel update of record/object reference while its field is accessed within a lock?
• When it comes to nested record field access, are we locking all the fields or only the leaf node?
  Eg:- Consider the field access of person.address.street within a lock
  should we lock access to both the address field of person and street field of address?

[jclark]

Nothing special about record or object references: lock behaves as if it acquires a single, global, recursive mutex.