Si verifica un cambio di contesto in un sistema la cui coda pronta ha solo un processo e che utilizza la pianificazione round-robin?

Question

Un commutatore di contesto si verifica in un sistema la cui coda pronta ha solo un processo e che utilizza la pianificazione round-robin?

Si supponga che l'attuale cpu burst del processo solitario si estenda su più di una porzione di tempo dell'algoritmo round-robin.

mio ragionamento è come sotto

I passi che possono aver luogo quando si verifica un interrupt timer in un caso tipico sono verifica

1. Interrupt. Passa alla modalità kernel
2. OS salva contesto attuale in PCB (salvare i registri, stato del processo e di gestione della memoria informazioni di processo in corso)
3. eseguire molte operazioni specifici per l'architettura, tra cui vampate di calore dati e le cache di istruzioni e TLB di.
4. Mettere processo in corso nella coda pronta
5. Scegliere il nuovo processo per eseguire
6. contesto carico dal PCB di quel processo
7. Passa alla modalità utente. Iniziare l'esecuzione del nuovo processo

Ora sto pensando che il sistema operativo potrebbe anche esaminare prima la coda pronta e verificare se ci sono altri processi. Se non ce ne sono, non c'è bisogno di un interruttore di contesto. Quindi la gestione dell'interrupt del timer comporterà il passaggio tra la modalità utente e la modalità kernel, controllando la Q pronta e tornando alla modalità utente per riprendere l'esecuzione del processo.

E 'questo che succede? Oppure un corretto passaggio al contesto che comporta il salvataggio non necessario dello stato attuale del processo solitario e il ripristino dello stesso avviene?

Se succede più tardi, c'è un motivo speciale?

Questa confusione è sorto a causa di una domanda in un documento di esame riguardante il calcolo del tempo trascorso nel cambio di contesto in tale situazione. La risposta fornita implica che gli switch di contesto abbiano luogo.

Spero che le persone che hanno esaminato il codice del kernel saranno in grado di fare luce su questo. Quindi questa domanda su StackOverflow.

Answer 1

Il seguente codice da Linux Kernel chiarirà il tuo dubbio. In momenti diversi, il kernel chiamerà lo scheduler per selezionare un nuovo processo da eseguire. Ma potrebbe accadere che lo scheduler non trovi altra attività tranne l'attività attualmente in esecuzione. In tal caso, lo scheduler non eseguirà un "cambio di contesto", piuttosto semplicemente restituirà non facendo nulla.

Per esempio, ti do il codice del kernel di Linux

......... 
    if (likely(prev != next)) {<-- if next and current are same, then no context switch 
      sched_info_switch(prev, next); 
      perf_event_task_sched_out(prev, next); 

      rq->nr_switches++; 
      rq->curr = next; 
      ++*switch_count; 

      context_switch(rq, prev, next); /* unlocks the rq */ 
      /* 
      * The context switch have flipped the stack from under us 
      * and restored the local variables which were saved when 
      * this task called schedule() in the past. prev == current 
      * is still correct, but it can be moved to another cpu/rq. 
      */ 
      cpu = smp_processor_id(); 
      rq = cpu_rq(cpu); 
    } else { 
    ............