Little's law can be used to describe a system in steady state from a queuing perspective, i.e. arrival and leaving rates are balanced. In this case it is a crude way of modelling a system with a contention percentage of 100% under Amdahl's law, in that throughput is one over latency.
However this is an inaccurate way to model a system with locks. Amdahl's law does not account for coherence costs. For example, if you wrote a microbenchmark with a single thread to measure the lock cost then it is much lower that in a multi-threaded environment where cache coherence, other OS costs such as scheduling, and lock implementations need to be considered. Universal Scalability Law (USL) accounts for both the contention and the coherence costs. http://www.perfdynamics.com/Manifesto/USLscalability.html When modelling locks it is necessary to consider how contention and coherence costs vary given how they can be implemented. Consider in Java how we have biased locking, thin locks, fat locks, inflation, and revoking biases which can cause safe points that bring all threads in the JVM to a stop with a significant coherence component. On Friday, 15 September 2017 02:30:55 UTC+1, Dain Ironfoot wrote: > > Hi Guys, > > Can someone verify if my understanding of Little's law is correct in the > context of locking. > > Suppose I have a system where I acquire a lock, do some work and release > it. Further, suppose that doing some "work" takes no time. > > > *λ = L/ *W ( *λ = throughout, L=Average number of customer > in a stable system, W=Average time spent in the system)* > > *λ = 1/* W (Since a lock will only allow one thread to > execute) > > *λ = 1/*10 micros (Supposed average time taken to acquire the lock) > > *λ **= *100,000 per second > > > Therefore, just by using a lock, the throughput of my system is capped at > 100,000 > per second. > > Is my reasoning correct? > > > Thanks > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
