What if your elevator or disk could magically know the best path to serve everyone quickly?
Why Scheduling algorithm (SCAN, LOOK) in LLD? - Purpose & Use Cases
Start learning this pattern below
Jump into concepts and practice - no test required
Imagine you are managing a busy elevator in a tall building. Without a smart plan, the elevator moves randomly, going up and down without order, making people wait long and wasting energy.
Manually deciding which floor to visit next can be slow and confusing. It causes delays, wastes time, and frustrates users because the elevator might zigzag inefficiently, just like a disk head moving back and forth without a plan.
Scheduling algorithms like SCAN and LOOK organize the elevator's movement by sweeping in one direction, serving requests in order, then reversing. This reduces wait times and travel distance, making the system smooth and efficient.
while requests:
next_floor = random.choice(requests)
move_to(next_floor)
requests.remove(next_floor)direction = 'up' while requests: floors_in_direction = get_floors_in_direction(current_floor, direction) serve_floors_in_order(floors_in_direction) direction = reverse(direction)
It enables fast, predictable, and fair servicing of requests, improving overall system performance and user satisfaction.
Disk scheduling in operating systems uses SCAN and LOOK to decide the order of reading or writing data, minimizing the disk arm movement and speeding up access.
Manual scheduling causes inefficiency and delays.
SCAN and LOOK algorithms organize requests by direction to optimize movement.
This leads to faster, fairer, and more predictable service.
Practice
Solution
Step 1: Understand SCAN behavior
SCAN moves the disk head to the end of the disk in one direction, servicing requests along the way.Step 2: Understand LOOK behavior
LOOK moves the disk head only as far as the last request in the current direction, then reverses.Final Answer:
LOOK stops at the last request in the direction, SCAN goes to the disk edge -> Option CQuick Check:
LOOK stops early, SCAN goes to edge [OK]
- Confusing which algorithm stops at disk edge
- Thinking LOOK moves randomly
- Assuming SCAN moves only one way
Solution
Step 1: SCAN moves towards higher end first
Starting at 50, SCAN moves up servicing 70 and 90, then reaches disk edge 100.Step 2: SCAN reverses direction
After reaching 100, it moves down servicing 35, 20, and 10.Final Answer:
50 -> 70 -> 90 -> 100 -> 35 -> 20 -> 10 -> Option BQuick Check:
SCAN goes to edge 100 before reversing [OK]
- Not including disk edge in the path
- Reversing direction too early
- Skipping requests on the way
Solution
Step 1: LOOK moves towards higher requests first
Starting at 40, it services 70 and 90, stopping at last request 90.Step 2: LOOK reverses direction
Then it moves down servicing 35, 20, and 10, stopping at last request in that direction.Final Answer:
[40, 70, 90, 35, 20, 10] -> Option DQuick Check:
LOOK stops at last request, no disk edge [OK]
- Including disk edge in LOOK path
- Reversing direction too early
- Skipping requests on the way
requests = [20, 40, 60, 80]
head = 30
for track in range(head, 100):
if track in requests:
print(f"Servicing {track}")
for track in range(head-1, -1, -1):
if track in requests:
print(f"Servicing {track}")Solution
Step 1: Check range end in first loop
range(head, 100) goes from 30 to 99 (exclusive end), missing disk edge at 100.Step 2: Confirm disk convention
As per standard problems (disk size 100 includes edge 100), first loop should be range(head, 101) to reach 100.Final Answer:
The first loop should go to 101, not 100 -> Option AQuick Check:
range exclusive, edge 100 needs 101 [OK]
- Confusing inclusive vs exclusive range ends
- Starting second loop incorrectly
- Assuming head position is included twice
Solution
Step 1: Initial direction to lower tracks
Lower requests: 50, 10. Path: 100 -> 50 (50 tracks), 50 -> 10 (40 tracks). Subtotal: 90.Step 2: Reverse direction to higher tracks
Higher requests: 120, 180. Path: 10 -> 120 (110 tracks), 120 -> 180 (60 tracks). Subtotal: 170.Step 3: Total head movement
90 + 170 = 260 tracks.Final Answer:
260 tracks -> Option AQuick Check:
Sum of |current - next| over servicing sequence [OK]
- Including disk edges in LOOK movement
- Adding extra distances beyond last requests
- Misordering request servicing
