☕ CafeteriaPay — Concurrent Payment Processing System

CafeteriaPay is a Python-based Operating Systems simulation of a real-time university cafeteria payment system.

The project demonstrates how multiple POS counters and payment workers can safely process concurrent wallet transactions using multithreading, bounded queues, semaphores, mutex locks, per-wallet synchronization, and priority scheduling.

A Tkinter dashboard is included for monitoring wallet balances, queue activity, processing statistics, student creation, manual payment requests, and wallet funding.

---

📌 Project Overview

During busy cafeteria hours, several payment counters may submit payment requests at the same time. The backend has limited queue capacity and only a few workers available to process those requests.

The system must ensure that:

• wallet balances are updated safely;
• two workers cannot modify the same wallet simultaneously;
• pending requests do not exceed the queue capacity;
• producers wait when the queue is full;
• consumers wait when the queue is empty;
• rush requests receive priority without completely starving normal requests;
• successful and failed transactions are logged;
• queue and payment statistics remain visible while the simulation runs.

CafeteriaPay models this scenario as a classic producer-consumer concurrency problem.

---

🎯 Operating Systems Concepts Demonstrated

Concept	Implementation
Multithreading	POS counters, workers, monitor and GUI operate through separate threads
Producer-Consumer Model	Producers generate requests and consumers process them
Bounded Buffer	Pending requests are stored in a fixed-capacity queue
Semaphores	Empty and filled queue slots control producer/consumer blocking
Mutex Lock	Protects shared queue operations
Per-Account Lock	Prevents race conditions during wallet balance updates
Priority Scheduling	Rush payments are processed before normal requests
Fairness	Scheduler attempts a 2 Rush → 1 Normal processing pattern
Critical Section	Balance checking and deduction occur while holding a wallet lock
Logging	Transactions and processing results are recorded
Real-Time Monitoring	Dashboard displays queues, counters and balances

---

✨ Features

• Multiple synchronized student wallet accounts
• Rush and normal payment-request queues
• Fixed-capacity bounded queue
• Two concurrent payment worker threads
• Safe wallet balance deductions
• Insufficient-balance detection
• Priority-based request processing
• Real-time queue statistics
• Produced, consumed, successful and failed payment counters
• Transaction logging to console and file
• Student creation through the dashboard
• Manual payment request submission
• Wallet funding option
• Tkinter-based live monitoring dashboard

---

🧩 System Architecture

POS Counter / Manual Request
            ↓
      Bounded Queue
     ┌──────────────┐
     │ Rush Requests│
     │Normal Requests
     └──────────────┘
            ↓
     Priority Scheduler
            ↓
      Worker Threads
            ↓
      Account Manager
            ↓
      Logger + Monitor
            ↓
      Tkinter Dashboard

---

🔄 Request Processing Flow

1. A payment request is created with:
   • request ID
   • student ID
   • payment amount
   • priority
   • timestamp
2. The request is inserted into the bounded queue.
3. A worker waits for an available request.
4. The scheduler selects a rush or normal request.
5. The worker acquires the selected wallet's lock.
6. The system checks whether the wallet has enough balance.
7. The amount is safely deducted or the request is marked as failed.
8. The result is written to the console and execution log.
9. The dashboard updates queue sizes, statistics and balances.

---

📁 Repository Structure

CafeteriaPay-Concurrent-Payment-System/
│
├── src/
│   ├── main.py
│   ├── account_manager.py
│   ├── queue_manager.py
│   ├── producer.py
│   ├── consumer.py
│   ├── scheduler.py
│   ├── logger.py
│   ├── monitor.py
│   └── monitor_gui.py
│
├── screenshots/
│   ├── 01-dashboard-overview.png
│   └── 02-priority-scheduling-console.png
│
├── logs/
│   └── sample_execution_log.txt
│
├── requirements.txt
├── .gitignore
└── README.md

---

🖼️ Screenshots

Live Dashboard

The dashboard displays:

• rush and normal queue sizes;
• produced, consumed, successful and failed payment counts;
• student wallet balances;
• student creation controls;
• manual payment requests;
• wallet funding controls.

Priority Scheduling and Concurrent Processing

The console demonstrates multiple worker threads processing rush and normal requests and logging successful transactions.

---

🛠️ Technologies Used

Category	Technology
Programming Language	Python
GUI	Tkinter
Concurrency	threading
Synchronization	Locks, mutexes and semaphores
Scheduling	Custom priority scheduler
Logging	Console and text-file logging
Interface	Desktop dashboard + console output

---

🚀 How to Run Locally

1. Install Python

Python 3.10 or newer is recommended.

Check your installation:

python --version

On some systems:

python3 --version

2. Clone the Repository

git clone https://github.com/fayzliaqat/CafeteriaPay-Concurrent-Payment-System.git
cd CafeteriaPay-Concurrent-Payment-System

3. Run the Application

From the repository root:

python src/main.py

On some systems:

python3 src/main.py

The console simulation will start and the Tkinter dashboard will open.

---

📦 Dependencies

No third-party Python package is required.

The project uses modules available in the Python standard library, including:

threading
tkinter
time
random
uuid
datetime
pathlib

On some Linux distributions, Tkinter may need to be installed separately:

sudo apt install python3-tk

---

🖥️ Dashboard Controls

Create Student

Creates a wallet account using the entered name and initial balance.

Manual Payment Request

Allows the user to:

• select a student;
• enter a payment amount;
• choose Rush or Normal priority;
• add the request to the processing queue.

Fund Selected

Adds funds to the selected student's wallet.

Clear Queues

Clears the currently displayed rush and normal queues.

---

🧪 Example Console Output

Starting CafeteriaPay Simulation

AUTO CREATED: SID-001($100) | SID-002($150) | SID-003($200)
Priority test queue ready

Worker-0 → Rush REQ | SID3
Worker-1 → Rush REQ | SID1
Worker-0 → Normal REQ | SID2
Worker-1 → Normal REQ | SID1

Worker-0 processed rush1 | Student: 3 | Amount: $25 | Priority: Rush | Status: SUCCESS
Worker-1 processed rush2 | Student: 1 | Amount: $10 | Priority: Rush | Status: SUCCESS
Worker-0 processed norm1 | Student: 2 | Amount: $15 | Priority: Normal | Status: SUCCESS
Worker-1 processed norm2 | Student: 1 | Amount: $20 | Priority: Normal | Status: SUCCESS

---

🧵 Main Modules

account_manager.py

Creates and manages wallet accounts and performs synchronized balance updates.

queue_manager.py

Stores rush and normal requests and controls bounded-buffer access using synchronization primitives.

producer.py

Generates payment requests and submits them to the queue.

consumer.py

Represents payment workers that retrieve and process pending requests.

scheduler.py

Implements rush/normal priority selection and fairness logic.

logger.py

Records request production, consumption and payment results.

monitor.py

Displays queue and transaction statistics.

monitor_gui.py

Provides the live Tkinter dashboard and manual controls.

main.py

Initializes accounts, queues, workers, monitoring and the dashboard.

---

🔒 Synchronization Strategy

Queue Synchronization

The queue is shared between request producers and worker consumers.

It is protected using:

• an empty-slot semaphore;
• a filled-slot semaphore;
• a mutex for rush and normal queue modifications.

Wallet Synchronization

Each wallet contains its own lock.

This allows different wallets to be updated concurrently while ensuring that only one worker can check and modify the same wallet balance at a time.

Priority and Fairness

Rush requests receive higher priority. The scheduler uses a fairness rule intended to process:

2 Rush requests → 1 Normal request

when both types are available.

---

✅ Project Requirements Covered

• Student wallet accounts
• Payment request objects
• Producer and consumer architecture
• Bounded payment queue
• Concurrent worker threads
• Rush and normal priority levels
• Fair scheduling policy
• Safe wallet deductions
• Successful and failed payment logging
• Real-time queue and processing statistics
• Execution log
• GUI-based monitoring

---

⚠️ Current Limitations

• The project is a simulation rather than a production payment platform.
• Data is stored in memory and resets after the application closes.
• There is no database or user authentication.
• Payment requests are generated locally.
• The dashboard is designed for desktop execution.
• Queue-clearing and shutdown behavior can be improved further.

---

🔮 Future Improvements

• Add graceful thread shutdown
• Add persistent wallet and transaction storage
• Add detailed transaction-history tables
• Add configurable queue capacity
• Add configurable producer and worker counts
• Add automated tests for concurrency behavior
• Add charts for payment throughput and failure rates
• Export transaction history to CSV
• Add role-based login for administrators
• Improve queue reset behavior

---

🏷️ Suggested GitHub Topics

python
operating-systems
multithreading
concurrency
producer-consumer
semaphore
mutex
thread-synchronization
priority-scheduling
tkinter
bounded-buffer
academic-project

---

👨‍💻 Author

Fayz Liaqat
Artificial Intelligence Student