3 posts
Grouping 10,000+ same-category notifications into one third-party group meant the chunks a batch server throws as jobs get consumed asynchronously. Where waiting-children fits in keeping one group and one send on top of that, and how five races were closed one by one and verified with invariants.
This article explores how the JVM monitor behind synchronized actually works, examines the concurrency-control features provided by ReentrantLock, and solves the producer-consumer problem that can arise in concurrent programs. It then improves performance with a lock-striping strategy based on per-user keys.
Suppose we are designing a first-come, first-served event system. The requirements are listed below. If 1,000 people request 100 available items at the same time, how can we ensure that exactly 100 people receive one? The solutions commonly proposed in this situation are listed below.