feat(job-array-one-based-index): collision checks after registration (task 2.3)

handle_jobsubmit now registers the submission first and checks the job
table second; a hit is answered -EEXIST and released through the atomic
reply-and-release step. For array submissions, array_identity_exists()
does one read-locked scan of the 32768 tagged element keys of the
array's block (element 0 included for pre-upgrade arrays), covering
both the element range and the array identity; unmarked submissions
keep jobid_range_exists. An existing X|3 now blocks a new X|5.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Rongsong Shen 2026-10-01 10:14:47 +00:00
parent 81bfaf1f50
commit fe5ddc9854
Signed by untrusted user: rshen
GPG key ID: 80533536B0EB651C
5 changed files with 278 additions and 27 deletions

View file

@ -43,7 +43,7 @@
- Done when the controller suite shows, from inside the hook, that the registry lock is held, the reply is already queued and the entry is still present; that the entry is gone afterwards; and that a retry of the same submission registered after the reply survives the original's context release
- _Requirements: 7.7, 7.10, 7.11_
- [ ] 2.3 Check element and array-identity collisions after registration
- [x] 2.3 Check element and array-identity collisions after registration
- Move the job-table collision checks after registration; on a hit, reply duplicate-submission and release through the atomic step
- For array submissions, one scan under a single job-table read lock over the 32768 element keys of the array's block answers both the element-range and the array-identity check; unmarked submissions keep the existing range check
- Done when the controller suite shows: an existing element `X|3` blocks a new `X|5` with duplicate-submission; two concurrent submissions with the same array identity, the second gets duplicate-submission while the first is unanswered; once the first is answered with a failure, a new one with the same identity is accepted