Technology Stack
Process Synchronisation, Inter-Process Communication, Mutual Exclusion Algorithms, Cloud File Sync, Cross-Platform Development
Overview
Duration: 1/2022
A screen-time management system in two parts: an enforcement agent running on the child's computer, and a control application the parents run from their own devices. The agent authenticates the user, checks the current time against an allowed-usage policy, monitors an active session, and shuts the machine down when the allowance is exhausted.
The reason this is a systems project rather than an application project is a single line in the requirements: both parents may run the control app simultaneously, from different machines, on different operating systems, editing the same policy file. That turns a scheduling tool into a distributed mutual-exclusion problem, and getting it wrong corrupts the policy that everything else depends on.
The Enforcement Agent
Runs at startup and cannot be trivially dismissed. Its control flow:
- Authenticate — read a password from the keyboard
- Parent override — if the parent password is entered, suspend enforcement for 60 minutes, since the parent using the machine is not the case being policed
- Blocked period — if the current time falls outside the allowed window, announce when use resumes, then run two things concurrently: a 15-second countdown to an unconditional shutdown, and a second authentication attempt, so a parent can still intervene before the machine powers off
- Failed authentication — three wrong attempts blocks the machine for 10 minutes and shuts it down, so the lockout cannot be brute-forced
- Active session — with a valid child password inside an allowed window, the agent runs a monitoring loop performing three tasks concurrently: periodic activity capture, live re-reading of the policy so a parent's change applies without a restart, and countdown warnings at the one-minute mark before shutdown
The Policy Format
Allowed usage is expressed in a compact line-based format, one rule per line:
F06:00 T06:45
F07:30 T11:30 D60 I20 S150
F19:00 T21:30 S90
Where F/T are the window bounds, D is the maximum continuous session, I the mandatory break between sessions, and S the total allowance within the window. The three rules above read as: free use from 06:00 to 06:45; between 07:30 and 11:30, 150 minutes total in blocks of at most 60 with 20-minute breaks; and between 19:00 and 21:30, 90 minutes total taken at any time.
Expressing the policy declaratively rather than as code is what lets both applications — written for different platforms — share one source of truth without shipping shared logic.
The Concurrency Problem
The policy file is synchronised through cloud storage so control apps on any platform can reach it. That is also what creates the hazard: two parents editing concurrently is a textbook critical section, and a naive read-modify-write loses one parent's change or corrupts the file outright.
The system coordinates access explicitly rather than hoping the window is too small to matter:
- Mutual exclusion on the policy file — a parent's edit acquires exclusive access before the read-modify-write and releases it afterwards, so the two updates serialise instead of racing
- Coordination across machines and operating systems, which rules out any single-host primitive and forces the lock into the shared medium itself
- Deadlock avoidance — the acquisition protocol is designed so a control app that crashes mid-edit cannot leave the policy permanently locked, which is the failure mode that turns a safety mechanism into a denial of service
- Concurrency within the agent — the monitoring loop's three tasks share state and are coordinated so a policy update landing mid-countdown is applied consistently rather than partially
The Control Application
Runs on the parent's phone or computer and provides policy viewing and editing, plus access to the activity history the agent has recorded — the current day at minimum, with historical access as an extension.
This project is operating-systems fundamentals applied to a real scenario: mutual exclusion, deadlock avoidance, inter-process communication, and concurrent task coordination — where the correctness requirement comes from an ordinary use case rather than a contrived one.