Why does TaskletStep use a Semaphore?

[reflash407]

Hi,

I’m currently studying the internals of Spring Batch, and I came across the use of a Semaphore in TaskletStep.

Here is the relevant source code:

https://github.com/spring-projects/spring-batch/blob/main/spring-batch-core/src/main/java/org/springframework/batch/core/step/tasklet/TaskletStep.java

protected Semaphore createSemaphore() {
    return new Semaphore(1);
}

As I understand it, synchronization is needed because multiple chunks can run concurrently in a multi-threaded step, while their contributions are eventually applied to the same StepExecution and persisted through the JobRepository.

What I am curious about is why Semaphore(1) was chosen specifically.

Since this seems to be a mutual-exclusion requirement, I initially thought that a lock such as ReentrantLock could also be used.

Unlike an ownership-based lock, a semaphore allows a permit to be released by a thread other than the one that acquired it. Was this property needed in any intended execution scenario, or was the semaphore simply being used as a binary lock here?

I am not suggesting that the implementation should be changed. I am just interested in understanding whether there was a specific design or historical reason behind this choice.

I looked through the source code and some related issues, but I could only find explanations for why synchronization was needed, not why Semaphore itself was selected.

Thanks in advance for any context.

[Samielakkad]

History points to this being a binary lock, rather than a deliberate use of cross-thread permit handoff.

Before 2008, TaskletStep delegated to JdkConcurrentStepExecutionSynchronizer. That class was itself only a Semaphore(1) wrapper: lock() called acquire() and release() called release(). BATCH-913 removed the synchronizer abstraction and inlined the same semaphore in TaskletStep; it did not introduce a new locking model.

BATCH-1708 later moved the semaphore from an instance field into doExecute(), making it shared only by chunks in one step execution, and added createSemaphore() as a test extension point. That matches the current comment and implementation.

The important current behavior is the lock lifetime: it is acquired immediately before applying the contribution and updating the shared StepExecution/repository state, then released as late as possible from TransactionSynchronization.afterCompletion() (acquire/release sites). This keeps concurrent chunks serialized through transaction completion.

A ReentrantLock could also express mutual exclusion, but it would not be a drop-in replacement because unlocking is owner-thread constrained, while this code deliberately separates acquisition and release across the transaction callback and completion callback. I could not find evidence that non-owner release was itself a required scenario; the historical record suggests Semaphore(1) was retained because it already implemented the old lock()/release() contract correctly.