A Scheduling Test, Slow Group Theory, and Questions That Looked Scarier Than They Were

Day 52 of my GATE CSE 2027 preparation was mostly about two things: continuing my work in Discrete Mathematics and taking another topic-wise test.

The interesting part of the day was not really the final test score.

It was understanding why I got certain questions right, why I got others wrong, and why I skipped a few questions that turned out to be much easier than they initially looked.

Apparently, my brain has developed a habit of occasionally seeing mathematical notation and immediately assuming the question is planning something personal against me.

A Small TOC Warm-up

I had postponed my TOC warm-up from the previous plan, so I completed it today.

The warm-up was scheduled for around 30 minutes, and I spent approximately that amount of time revising about half of the first chapter of Theory of Computation.

I haven't solved questions from that portion yet. Instead, I plan to use the Sunday flexi slot from my November schedule to practise the relevant questions.

I think this separation works well for now.

The warm-up refreshed the concepts without turning into another full-length revision session. With the number of subjects I am currently juggling, every 30-minute task has the potential to suddenly become a three-hour adventure if I'm not careful.

Completing Group Theory Lecture 1

I also continued with Group Theory in Discrete Mathematics.

Group Theory has been moving slowly for me, and I'm deliberately not trying to force myself through it just to match the original schedule.

For GATE CSE preparation, Discrete Mathematics is important, and I would rather spend additional time understanding it properly than rush through a lecture and later discover that I remember absolutely nothing except the lecture thumbnail.

By the end of the day, I had:

• Completed Group Theory Lecture 1
• Started Group Theory Lecture 2

The notes for Group Theory are still pending.

That is something I need to watch carefully. I already learned during my Compiler Design preparation that completing lectures while allowing notes to accumulate can create an unnecessary backlog later.

The November schedule is also moving slower than expected because I have topic-wise tests scheduled regularly, and I need revision time for those tests as well.

So for now, my approach is simple: adjust the schedule when necessary rather than rushing through Discrete Mathematics and Engineering Mathematics.

Even if these subjects take longer, I want the understanding to stay.

---

Operating Systems Topic Wise Test 1

The major test of the day was:

GO Classes CS Test Series | Operating Systems | Topic Wise Test 1

My final result was:

View my Operating Systems Topic Wise Test 1 result →

The test mainly involved CPU scheduling, although some questions also touched related Operating Systems concepts such as threads, process states, locks, and system calls.

I had revised scheduling concepts, but I hadn't revised all of those surrounding topics.

That distinction became important during the test.

My Scheduling Concepts Were Better Than My Speed

One thing became clear after analysing the entire test.

I still understand most of the CPU scheduling concepts.

I correctly solved several questions involving:

• SRTF
• FCFS
• Priority Scheduling
• Scheduling order
• Waiting time
• Turnaround time

The problem was that I was slow.

I had not practised scheduling problems for some time, so even when I knew the concept, I spent much longer than expected creating timelines and verifying calculations.

For example, I solved some SRTF questions independently, but they still took several minutes.

I don't think getting a correct answer slowly is automatically a bad thing.

The progression should ideally be:

Correct but slow → Correct and faster

Trying to jump directly to speed without accuracy is just an efficient way of producing wrong answers.

So the goal now is to restore speed through practice.

A Reminder About Blocked and Ready States

One of my mistakes involved process/thread state transitions.

I incorrectly connected an event such as I/O completion directly to the Running state.

The important sequence is:

Blocked → Ready → Running

When I/O completes or a thread is woken up, it becomes Ready.

It still needs to be selected by the scheduler before it can become Running.

This mistake was partly because I had revised scheduling but hadn't recently revised related concepts involving process states, locks, and semaphores.

The test was a useful reminder that subjects do not always stay neatly inside the chapter boundaries we create in our notes.

How inconvenient of Operating Systems to connect its own concepts.

What Threads Actually Share

Another question asked what is shared between threads of the same process.

I was confident about the Code/Text segment because I remembered the standard process memory layout:

• Stack
• Heap
• Data segment
• Text/Code segment

But I wasn't confident about the Heap.

The correct idea is that threads in the same process share the process address space, including:

• Heap
• Code/Text

However, each thread has its own:

• Stack
• Register context

This wasn't a completely unknown concept. I simply hadn't connected my understanding of process memory layout with the concept of multiple threads inside the same process.

My Favourite Kind of Mistake: Off-by-One

One of the most painful mistakes came from a FIFO scheduling question.

I spent almost eight minutes solving it.

My overall approach was fine.

Then I made a silly timeline mistake.

I treated the final time at which a process was executing as its completion time.

For example, if a process executed during:

1 → 2
2 → 3
3 → 4

I treated the completion time as 3 because that was the last execution slot shown.

But the process actually completes at 4, at the end of its final execution interval.

That one mistake propagated through the calculation, and I ended up getting 1 instead of 5.

A nearly eight-minute calculation defeated by one tiny timeline mistake.

A beautiful example of why GATE preparation occasionally feels like arguing with a calculator that has developed emotions.

The correct takeaway is simple:

The completion time is the end of the final execution interval, not the beginning of it.

The Round Robin Question I Thought Was Too Long

One Round Robin question had service times given in seconds and a time slice of 10 milliseconds.

I knew how to perform Round Robin scheduling.

But when I saw the tiny time quantum compared with the service times, I started imagining an enormous number of cycles:

P1 → P2 → P3 → P1 → P2 → P3...

and decided it would take too much time.

So I skipped it.

After analysing the question later, I realised there was a better way to think about it.

Instead of manually simulating every 10 ms time slice, the problem could be reasoned about using the approximate CPU share received by continuously active processes.

The lesson wasn't that I didn't know Round Robin.

The lesson was:

Knowing an algorithm and recognising the fastest way to analyse a particular question are two different skills.

The Question I Skipped Because It Looked Mathematical

Another question involved variables such as:

• Number of jobs
• Burst length
• Time slice

It was worth two marks.

I looked at the expression, assumed it would be difficult, and skipped it.

After the test, I solved it in under two minutes.

This was probably one of the most useful moments of the entire analysis.

I had made a decision about the difficulty of the question before actually analysing the underlying idea.

This isn't the first time I've done that either.

During the previous Data Structures test, I had skipped a mutual recursion question because it looked difficult, only to later realise it was manageable.

So I think there is a pattern here.

Sometimes I need to give a scary-looking question a short but genuine attempt before deciding whether it deserves to be skipped.

The notation is not always the enemy.

Sometimes it's just wearing glasses and trying to look intelligent.

A Correct Answer That I Don't Fully Trust

One question introduced a scheduling algorithm called Least Used First (LUF).

I had never previously practised this algorithm.

I spent more than nine minutes working through the question and somehow got the correct final answer.

However, there was a problem.

My Gantt chart was different from the official solution.

I also couldn't confidently remember whether I had consistently applied the LUF rule correctly throughout the calculation.

So although the answer was correct, I don't want to count it as a solid demonstration of understanding.

This is something I've become more conscious about during these topic-wise tests.

A correct answer can happen because of:

• genuine independent understanding,
• remembering a previously seen question,
• guessing,
• external confirmation,
• or pure luck.

The final score doesn't tell you which one happened.

The analysis does.

Another Correct Answer I Had Seen Before

One of the fastest answers in the test took me only around 24 seconds.

But that speed wasn't because I had suddenly become a scheduling genius.

I had already solved that exact question before and remembered the answer pattern.

So I used that memory and selected the option.

Again, the answer was correct.

But I shouldn't treat that as proof that I could independently solve the same pattern from scratch in 24 seconds.

This is why I want to keep analysing my tests rather than simply recording marks.

The number is useful.

The story behind the number is much more useful.

What the 64% Actually Means

My final score was 16/25, or 64%.

But after going through every question, I don't think the correct interpretation is simply:

“I know 64% of Operating Systems.”

That would be terrible analysis.

The actual picture is more specific.

What was working

• My CPU scheduling concepts were mostly still present.
• I could solve several SRTF, FCFS, and Priority Scheduling questions independently.
• Accuracy was generally reasonable when I gave myself enough time.

What needs improvement

• I am currently slow because I am out of practice.
• Some related OS concepts had not been revised.
• I sometimes judge questions as difficult too early.
• Timeline calculations need more careful attention.
• A correct answer should not automatically be treated as proof of mastery.

---

What Day 52 Taught Me

The biggest lesson from today's test was very similar to what I discovered during the previous Data Structures test.

Revision affects speed and confidence, not just whether I remember a concept at all.

My scheduling knowledge hasn't disappeared.

But without recent practice, familiar problems take longer, timelines feel less automatic, and I spend more time checking myself.

There is also another pattern I need to fix:

Don't let the appearance of a question decide whether I can solve it.

A complicated expression may be easy once the core idea is identified.

A simple-looking question can contain a silly trap.

The only reasonable approach is to actually analyse the question.

Meanwhile, Group Theory is moving slowly, and I'm okay with that.

I don't want to rush Discrete Mathematics or Engineering Mathematics just to satisfy a schedule.

The November plan is useful, but it is still a plan.

It can be adjusted.

Understanding the subjects properly while managing daily tests is going to take time, and for now, I would rather accept that than pretend speed is progress.

---

Tomorrow

The next steps are:

• Continue Group Theory Lecture 2
• Keep track of the pending Group Theory notes
• Continue following the November schedule while adjusting it where necessary
• Build more speed through repeated practice
• Avoid prematurely skipping questions just because they look complicated
• Continue using test analysis to distinguish between real understanding and lucky correctness

Day 52 was not a spectacular high-score day.

But it was a useful one.

And honestly, discovering exactly why I was slow felt more valuable than pretending that 64% was the entire story. 📚⏱️