idea for doing synchronous evals but _not_ holding evalLock

[davidkoski]

Proposed changes

• do the synchronous mutation under lock with asyncEval
• synchronous eval then does not need lock

Checklist

Put an x in the boxes that apply.

• I have read the CONTRIBUTING document
• I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
• I have added tests that prove my fix is effective or that my feature works
• I have updated the necessary documentation (if needed)

[davidkoski]

This is the heart of the change. we need the evalLock to guard against mutation of shared state. python uses thread-local streams to scope this, but we can't do that on the swift side (at least not in the same way).

But what if we did the mutation part under lock and then just wait for the arrays to be ready outside the lock? The MLXArray instances are still not thread safe, so they can't escape to other threads where the mutation could be observed, so I think this is safe.

See #472 and #62

[davidkoski]

FYI @aleroot -- I got this idea from the concurrent read work you did and this might be generally useful.

[aleroot]

Nice work.

[davidkoski]

For now this is just some tests that I had claude throw together.