Specifica del problema

Scrivere un programma multithread che consenta di valutare le performance, in termini di numero di page fault, di algoritmi di rimpiazzamento delle pagine per la gestione della memoria virtuale.

Il programma dovrà essere costituito da un’entità principale che operi come una Memory Management Unit (MMU), un numero arbitrario (n) di thread, ove ogni thread emuli un singolo processo (PROCESSO) e, infine, da un’entità che emuli un dispositivo di I/O (DISPOSITIVO I/O).

Il programma dovrà simulare una sessione di lavoro, nella quale sono presenti n processi che possono accedere alla memoria e generare richieste di I/O. I processi dovranno generare indirizzi di memoria casuali. Infine, il programma terminerà una volta raggiunto il numero prestabilito di accessi in memoria totali.

MMU

L’entità MMU sarà la base del sistema ed utilizzerà l’algoritmo di rimpiazzamento delle pagine oggetto di test. Essa dovrà essere istanziata dal thread principale (main) e sarà gestita come oggetto condiviso tra i diversi thread dei PROCESSI. In particolare essa definirà la dimensione dello spazio di indirizzamento virtuale, la dimensione della memoria fisica disponibile e la dimensione della pagina.

La MMU dovrà, inoltre, contenere una lista di tabelle della pagine ciascuna relativa ad un PROCESSO. La definizione della specifica delle tabelle delle pagine sarà lasciata allo studente, e naturalmente dipenderà dal particolare algoritmo di rimpiazza mento implementato.

I PROCESSI dovranno generare indirizzi verso la MMU invocandone un metodo pubblico.

L’accesso a tale metodo dovrà garantire la mutua esclusione (un solo PROCESSO alla volta potrà invocare il suddetto metodo. La mutua esclusione dovrà essere ottenuta utilizzando le primitive di sincronizzazione messe a disposizione dal linguaggio di programmazione eccezion fatta per il costrutto monitor (per chiarezza, ad esempio, in java non sarà possibile utilizzare il costrutto synchronized) .

Il metodo in questione processerà la richiesta andando ad interrogare l’opportuna tabella delle pagine. Nel caso in cui, l’indirizzo generato sia relativo ad una pagina già mappata in memoria la MMU si limiterà ad incrementare un contatore statistico di page hit. D’altra parte, nel caso in cui l’indirizzo generato dal PROCESSO faccia riferimento ad un indirizzo contenuto in una pagina non mappata in memoria la MMU dovrà eseguire i seguenti passi:

• incrementare un contatore di page fault
• selezionare una pagina mappata da rimuovere (vittima) secondo la politica dell’algoritmo oggetto di test.
• aggiornare le opportune tabelle delle pagine
• indicare come non valida la pagina che è appena stata rimossa.
• inserire una nuova entry nella tabella delle pagine del PROCESSO che ha
• generato il page fault (la pagina è stata appena caricata).

PROCESSO

L’entità PROCESSO dovrà emulare un processo in esecuzione su di un sistema multi programmato. Ogni processo dovrà essere emulato attraverso l’utilizzo di un singolo thread. Lo scheduling dei thread sarà delegato alle librerie messe a disposizione dal linguaggio di programmazione (configurazione default).

Il comportamento di ogni PROCESSO può essere descritto da una macchina a stati finiti comprendente due soli stati mutuamente esclusivi:

• Richiesta indirizzo di memoria (invocazione del metodo pubblico della MMU).
• Richiesta operazione di I/O (invocazione del metodo pubblico del DISPOSITIVO di I/O).

Le transizioni tra i due stati dovranno essere gestire in maniera probabilistica. In particolare, dovrà essere definita una probabilità p (input fornito al momento del lancio dell’applicazione) di generare indirizzi di memoria (“entrare nello stato a dato che ci si trovava nello stato b” = “rimanere nello stato a”) e una probabilità q = 1-p di generare richieste di I/O (“entrare nello stato b dato che ci si trovava nello stato a” = “rimanere nello stato b”)

I PROCESSI dovranno prevedere la possibilità di essere inizializzati con diversi valori di probabilità p.

DISPOSITIVO di I/O

L’entità DISPOSITIVO di I/O dovrà essere gestita come un ulteriore thread. Questa avrà un metodo pubblico attraverso il quale i PROCESSI potranno effettuare una richiesta di I/O.

Le richieste di I/O dovranno essere gestite con un coda di tipo FIFO. Le richieste saranno, ovviamente, bloccanti, mettendo il PROCESSO chiamante in uno stato di attesa fino al soddisfacimento della richiesta.

Il DISPOSITIVO di I/O determinerà il tempo di servizio di ciascuna richiesta in modo casuale estraendo a caso un valore intero, espresso in millisecondi, compreso fra Tmin e Tmax (parametri di inizializzazione del DISPOSITIVO di I/O).

Dati di INPUT

Il programma dovrà ricevere in input i seguenti parametri di inizializzazione:

• Numero di PROCESSI
• Probabilità p di generare accessi in memoria (una p per ogni PROCESSO; la probabilità di accedere al dispositivo di I/O sarà pari a 1-p)
• Tempi di servizio minimi e massimi del DISPOSITIVO di I/O (Tmin e Tmax).
• Numero totale di accessi in memoria raggiunto il quale il programma dovrà terminare.

Dati di OUTPUT

Al termine della simulazione il programma dovrà stampare a video la percentuale di page fault totale (relativa a tutti i processi), la percentuale di page fault relativa a ciascun PROCESSO, il tempo medio di servizio del DISPOSITIVO di I/O ed il tempo medio di attesa per una richiesta di I/O relativo a ciascun PROCESSO.

Ciascun PROCESSO dovrà scrivere in un proprio file di log la successione di indirizzi generata e le chiamate al dispositivo di I/O.

Analisi del problema

Il problema richiede di realizzare un simulatore elementare di memoria virtuale, utile all’analisi del comportamento e relative prestazioni di un algoritmo di rimpiazzo delle pagine. Il sistema realizzato simulerà un ambiente di lavoro multi programmato, nel quale operano più processi contemporaneamente.

Un’analisi iniziale ci suggerisce che questo problema sia di tipo decidibile, ovvero presuppone l’esistenza di un algoritmo che lo risolva in tempo finito e per una qualunque istanza di dati, espressa in termini di numero di processi contemporanei, dimensione della pagina e così via.

Come da specifica, il simulatore non avrà bisogno di alcun dato di ingresso per funzionare. Un insieme esteso di parametri da riga di comando permetterà di alterare alcuni aspetti e funzionalità del simulatore.

L’output del programma sarà costituito da alcuni dati statistici, prodotti a seguito del numero prestabilito di accessi alla memoria.

Progettazione dell’algoritmo

La scelta della struttura dati e del relativo algoritmo tiene conto dei parametri dettati dalla specifica del problema: l’attenzione sarà dunque focalizzata sulla politica di rimpiazzo delle pagine, sulle strutture dati necessarie ed sullo scenario che tali scelte determinano; l’analisi non terrà quindi in considerazione l’impatto che il paging nella memoria secondaria possa avere sull’efficienza complessiva del sistema, né dei tempi d’accesso alla memoria o di caricamento di una pagina.

Si è scelto di articolare il programma in tre fasi distinte:

1. analisi dei parametri forniti su riga di comando: di particolare rilievo, la possibilità di modificare alcuni parametri di funzionamento del simulatore;
2. inizializzazione delle strutture dati e successiva esecuzione dei singoli thread;
3. attesa del completamento dei thread, relativa deallocazione delle strutture dati e successiva stampa delle statistiche.

Descrizione del simulatore

Un sistema dotato del meccanismo di memoria virtuale consente ad un processo di allocare una quantità di memoria superiore a quella effettivamente disponibile. La tecnica si basa sull’utilizzo di altri tipi di memoria, detta secondaria, che entrano in gioco quando la memoria fisica risulta piena. Il meccanismo di memoria virtuale implementato per il simulatore è quello della paginazione.

La paginazione prevede la suddivisione della memoria fisica in frame, tutti della stessa dimensione; analogamente, anche la memoria allocata da un processo viene diviso in pagine, la cui dimensione è pari a quella di un frame di memoria fisica: tale suddivisione avviene ad opera della mmu, in modo totalmente trasparente al processo utente.

Al pari di un sistema operativo, il simulatore terrà aggiornata una tabella dei processi attivi: ogni voce nella tabella è rappresentativa di un processo e delle pagine virtuali allocate.

Perché un processo possa accedere ad un’informazione contenuta in una determinata pagina virtuale, è necessario che quest’ultima sia presente nella memoria fisica ovvero, nello specifico, che sia associata ad un frame. Quando la lista dei frame disponibili non è esaurita, sarà sufficiente associare la pagina richiesta ad un frame disponibile; nel caso contrario, si dovrà applicare una politica di rimpiazzo delle pagine, volta a selezionare una pagina tra quelle presenti in memoria, spostarla nella memoria secondaria e associare il frame appena liberato alla pagina richiesta.

L’algoritmo di rimpiazzo delle pagine scelto è l’enhanced second chance, noto anche come algoritmo dell’orologio: tale soluzione nasce come una naturale evoluzione della tecnica fifo, superando il problema di rimuovere le pagine usate più di frequente.

La realizzazione di tale algoritmo impone che ogni pagina contenuta nella page table del processo, oltre le comuni informazioni, debba contenere due ulteriori bit:

• bit reference (R): verrà posto al valore uno (1) quando si accederà alla pagina in questione, sia in scrittura che lettura: tale informazione permetterà di sapere se ad una pagina presente in memoria si sia acceduto di recente o meno;
• bit dirty (D): verrà posto ad uno (1) quando si accederà alla pagina  in scrittura: quando una pagina dovrà essere rimossa dalla memoria, il valore uno di questo bit suggerirà al sistema operativo di fare una copia della pagina nella memoria secondaria, prima della rimozione dalla memoria principale.

La ricerca della pagina virtuale da rimuovere dovrà tenere conto delle quattro possibili combinazioni ottenute con questi due bit:

Una simile suddivisione consente ad ogni processo di allocare un massimo di 256 pagine virtuali (2⁸), la cui dimensione è pari a 4,096 byte (2¹²): ovviamente il numero di pagine virtuali disponibili per un processo è indipendente dal numero di frame disponibili.Qualora il rapporto tra i frame disponibili ed il numero massimo di processi concorrenti risulti vantaggioso, il programma attiverà automaticamente la paginazione anticipata: l’MMU, infatti, non si limiterà a caricare in memoria la pagina mancante, causa del fault, ma anche un ristretto numero di pagine adiacenti. In pratica il simulatore cerca di prevedere quali pagine saranno richieste in virtù della località dei dati e le carica prima di quando queste vengano effettivamente richieste.

La suddetta funzionalità è da considerarsi puramente dimostrativa ed embrionale.

Di seguito vengono riassunte le scelte progettuali che caratterizzano il simulatore.

Hardware
Dimensione indirizzo	20 bit
Dimensione RAM	1,048,576 byte
Dimensione frame	4,096
Memoria virtuale
Tipo	paginata
Politica di rimpiazzo	enhanced second chance
Dimensione pagina	4,096
Page table	sempre in memoria
Max pagine/processo	256
Dispositivo I/O
Tmin	1
Tmax	100
Processo
Probabilità accesso	80%
Località temporale	30%
Località spaziale	Loop su un vettore

 Descrizione moduli

Di seguito verranno descritti,  con maggiore dettaglio, gli aspetti implementativi dei singoli moduli: l’MMU, il dispositivo di I/O ed il processo.

Ogni singolo modulo del simulatore viene inizializzato direttamente dal main() attraverso le rispettive funzioni e sulla base dei parametri specificati da riga di comando. Terminata questa fase, inizierà l’interazione tra i singoli thread.

Memory Management Unit (MMU)

Il thread che emula l’MMU è il primo ad essere istanziato dal simulatore, direttamente all’interno del main: questo si occupa della traduzione di un indirizzo virtuale, generato da un processo, in un equivalente indirizzo fisico di memoria.

La funzione mmu_init è incaricata di configurare l’ambiente del simulatore nonché di partizionare la memoria fisica in frame. Ad ogni frame verranno associate le seguenti informazioni:

• id: tale valore identifica univocamente un frame;
• physical_addr: questa variabile conterrà l’indirizzo di memoria fisica di partenza del frame; durante il ciclo di vita del simulatore, la lista dei frame non sarà ordinata per id: questo è il valore di base cui sommare l’offset dell’indirizzo virtuale;
• valid: il bit verrà posto ad uno (1) quando il frame è utilizzato;

Ad ogni frame vengono inoltre associate due ulteriori campi, pid e page_id: sebbene non siano necessari al funzionamento del simulatore, hanno il solo scopo di rendere più semplice il debug, nonché offrono la possibilità di mantenere un’associazione frame -> processo -> pagina.

 

L’MMU fa uso di due liste semplici: la prima, free_frames, per tenere traccia dei frame liberi (ovvero non associati ad alcuna pagina) ed used_frames per i frame utilizzati. Terminata l’inizializzazione della memoria, tutti i frame saranno presenti nella lista free_frames, condizione dettata dal demand paging. Un’ulteriore lista, active_pages, conterrà solo le pagine presenti in memoria.

La funzione thread_mmu viene eseguita come thread e simula l’MMU: l’interazione tra questo thread ed i processi è resa possibile dalla funzione memory_read, invocata direttamente dai processi che tentano un accesso alla memoria. Quest’ultima si occuperà di inserire in una struttura temporanea i dati relativi al processo chiamante, nonché l’indirizzo virtuale richiesto e segnalerà alla MMU la presenza di una richiesta; l’MMU, nel vagliare la richiesta, sceglierà quale frame associare alla pagina equivalente ed, al termine, restituirà l’indirizzo di memoria fisico.

Di seguito verrà illustrato lo schema a blocchi del funzionamento della MMU.

L’algoritmo enhanced second chance viene applicato solo quando la pagina richiesta non è presente in memoria ed, al contempo, tutti i frame risultano occupati. Ha quindi inizio una ricerca della pagina candidata alla rimozione: i due bit precedentemente descritti, reference e dirty, tengono traccia dell’uso e della modifica delle pagine.

L’algoritmo prevede che l’elenco delle pagine utilizzate sia rappresentato da una lista circolare, mentre è stata usata una lista doppiamente concatenata che, nel caso peggiore, viene visitata per intero.

Processo

La funzione thread_proc, eseguita come thread, si occupa di simulare un processo utente.

La rappresentazione in memoria del singolo processo, nonché delle caratteristiche che lo contraddistinguono, è affidata alla struttura proc. Avendo come riferimento un sistema operativo reale, al proprio interno, il simulatore gestisce una lista di tutti i processi attivi, detta process table: ogni voce in questa tabella è di tipo proc e contiene le seguenti informazioni:

• pid: identificativo univoco del processo;
• tid: identificativo univoco del thread che simula il processo;
• page_count: numero di pagine virtuali allocate dal processo;
• page_table: tabella delle pagine del processo; questa informazione non deve essere accessibile al processo;
• percentile: probabilità del processo di effettuare un accesso alla memoria piuttosto che al dispositivo di I/O;
• io_cond/io_lock: condizione e relativo mutex nel quale il thread resta in attesa di completamento di una richiesta di I/O;
• log_file: file di log del processo;
• proc_stats: struttura per contenere le statistiche d’accesso del processo.

Nei sistemi reali, un processo ha visibilità solo di alcune informazioni contenute nella process table o relative al sistema ospite: per esempio, un processo potrà sapere qual è il proprio pid o la dimensione della memoria virtuale, ma non potrà tuttavia accedere alla lista delle pagine o dei frame, informazioni ad unico appannaggio del sistema operativo. Seguendo le implementazioni dei più comuni sistemi *nix si è dunque scelto di non far gestire alla mmu la tabella delle pagine virtuali del processo, garantendo opportunamente la protezione dello spazio d’indirizzamento: l’mmu farà piuttosto uso di una propria struttura dati per gestire l’associazione delle pagine ai frame. Questa scelta trova ulteriore giustificazione nel fatto che ogni processo può allocare una quantità variabile di memoria e l’mmu, che viene inizializzata prima della process table, non può conoscere a priori tale quantità.

Poiché il simulatore non è stato implementato con un linguaggio orientato ad oggetti quale Java o C++, le api di accesso alla memoria ed al dispositivo di I/O devono contenere necessariamente l’identificativo del richiedente, nello specifico il pid.

La funzione proc_init ha il compito di creare n istanze del thread processo, per ognuno dei quali associa un numero casuale di pagine virtuali.

Il numero casuale di pagine virtuali è compreso tra 1 e 256, in modo tale che tutti i processi abbiano almeno una pagina associata e comunque non superiore al limite massimo di 256. È tuttavia possibile massimizzare tale valore per tutti i processi usando il parametro –M.

La funzione thread_proc, si occupa di scegliere se effettuare un accesso alla memoria o al dispositivo di I/O, scegliendo tra le due operazioni con una probabilità impostata dall’utente: quando la funzione memory_access, utilizzata per accedere alla memoria, restituirà il valore -1, i processi termineranno la propria esecuzione.

L’accesso in memoria osserva il principio di località, secondo cui:

• se accedo ad un dato, probabilmente accederò anche a quelli vicini in un tempo non lontano (località spaziale);
• se accedo ad un dato è probabile che debba accedervi nuovamente in breve tempo (località temporale).

La realizzazione della località spaziale viene offerta dalla funzione simulate_loop che si occupa di simulare un accesso ad un vettore di n elementi: poiché in C gli elementi di un vettore occupano indirizzi di memoria contigui, simulare un accesso ad ognuno di essi coincide ad una località spaziale.

Quando il processo effettua invece un accesso pseudo casuale alla memoria, subentra la località temporale, ovvero la possibilità di accedere ad un dato recentemente utilizzato. In quest’ottica, il processo avrà il 30% di probabilità di accedere ad un indirizzo di memoria usato in precedenza.

Il parametro “–L” permette di variare la percentuale di località temporale, di default pari a 30%; ponendo uguale a zero tale valore, si elimina l’effetto di località.

L’operazione di lettura merita ulteriori considerazioni:

1. nel caso di accesso alla memoria, l’indirizzo virtuale è generato casualmente, ma è sempre compreso nello spazio d’indirizzamento virtuale del processo: qualora l’indirizzo fuoriuscisse da tale spazio, il simulatore avrebbe il compito di generare un fault e terminare il processo;
2. per una migliore simulazione dell’algoritmo scelto, che prevede l’uso del bit dirty, è stata implementata l’operazione di scrittura in una zona di memoria: la funzione che realizza tale operazione è sempre memory_access ma con il parametro rw posto ad uno; non sarà tuttavia presente un parametro utile a rappresentare l’informazione da scrivere in memoria, in quanto esula lo scopo della presente analisi;
3. per entrambe le tipologie di accesso, alla memoria od al dispositivo di I/O, il processo non ha visibilità diretta dei rispettivi thread: la possibilità di effettuare una richiesta viene offerta dall’uso di due funzioni pubbliche che svolgono il ruolo di intermediario.

Sussiste una sottile differenza tra i due tipi di accesso che un processo utente può effettuare: l’MMU rappresenta un oggetto condiviso tra più processi e può assolvere una richiesta per volta; se n processi tentassero l’accesso alla memoria, soltanto uno riuscirà nell’intento mentre gli altri “n-1” processi restano in attesa (mutua esclusione).

Di contro, l’accesso al dispositivo di I/O prevede che effettuare una richiesta d’accesso non sia bloccante, per cui se n processi tentassero l’accesso al dispositivo, tutti quanti riuscirebbero ad inserire la propria richiesta in coda: l’attesa avviene immediatamente dopo, non bloccando quindi gli altri attori della contesa, ma solo il processo che attende il risultato.

Di seguito viene illustrato il diagramma a blocchi del funzionamento del thread processo.

I’ve already wrote the solution to this bug and soon I’ll release the new version which also includes a way to exclude person from sync.

Please, visit the following link: http://www.facebook.com/pages/YABI/

“This changes everything. Again.”

YABI core functions have been totally reimplemented and, above all, completed.
This version addresses few bugs, which caused YABI Agent crashes (e.g. when an event name is changed in AddressBook).

I’ve also been asked for new interesting features, I’ll work on them in spare time:

• use remote calendar as target
• excluding birthdays
• enhanced nickname support

Upgrade note
We suggest to deactivate YABI before upgrading; follow these few steps:

• Open YABI preference pane
• Click on Deactivate button and quit System Preferences
• Upgrade YABI by double-clicking on the new icon

Download YABI at http://www.devzero.it/yabi/ and check it out!

Here some changes:

• [FIX] Nicknames were not properly imported by from Sync Server and it was impossible to substitute in event title
• [FIX] Target calendar change is now saved
• [FIX] Event title changes are properly saved
• [FIX] Alarm icon column is no more bound to “data” binding (“value” is now used: no more warning in your console about this deprecated construct)
• [NEW] Agent deactivation removes application data file
• [NEW] Deactivate button is now disabled when a fresh-sync is issued
• [NEW] Added the new specifier “%yp” (equal to %y minus 1)

Here what must still be implemented:

• Software autoupdate

I’d like to thank all of you for your bug report and support.

You can download it at www.devzero.it/yabi

Here some changes:

• 64-bit enabled
• minor memory leaks fixed
• added “partner” attribute for anniversary cross-check
• UI updates
• removed unused frameworks

Here what must still be implemented:

• Save/restore event titles
• Software autoupdate

You can download it at www.devzero.it/yabi

DZSelectableBox is a subclass of NSBox view which emulates this behavior. An instance of this class comes with one more variable member, the box state: when the box is marked as selected, an inner rounded path is drawn inside its bounds; DZSelectableBox honors title position, if it’s visible. You can use this class in two different manners: standalone or as part of a radio group.

Standalone version

A standalone box works as described before: the only thing you’ve to do is open Interface Builder, place a common NSBox in your window, change its class name into DZSelectableBox and start using it.
You can change box state programmatically by using the toggleState message, the setSelected method to set its state or simply by clicking on it.

Radio group version

Whenever you need a group of boxes and the opportunity to select only one of them at time, you’ve to set a radio group; after you followed the steps described before to create your boxes, you’ve to add the following sample code to your application:

leftBox.radioGroup = [NSNumber numberWithInt:1]; 
rightBox.radioGroup = [NSNumber numberWithInt:1]; 
[leftBox setSelected:YES]; 
[rightBox setSelected:NO];

(we suppose you created two boxes and connected them to two outlets called leftBox and rightBox)

When a box belongs to a radio group, it listens for group changes notification: for example, if you select the right box (by clicking on it), the left one will be automatically unselected.

Where can I download the code?

Code is available on GitHub at the following url:

http://github.com/unixo/Selectable-Box

You can also download a Test application

This algorithm requires that each page contained in the page table, besides the common attributes, must also contains two further bits:

• reference bit (R): this bit will be 1 when the system accesses the page, both for read and write operations;
• dirty bit (D): this bit will be 1 only when the page will be written: when a page must be removed from main memory, this bit will remember the operative system to make a copy into secondary storage, before wiping it out.

Searching for a virtual page to be removed will take in account of four possible combinations:

1. R=0, D=0: this page has never been used nor modified -> remove this page
2. R=0, D=1: this page has not been recently used, but has been modified -> write it back to secondary storage and set D=0;
3. R=1, D=0: this page has been recently used only for read access -> set R=0
4. R=1, D=1: this page has been recently used and modified -> set R=0, do a write back and set D=0.

Searching for the best page to replace won’t only be equivalent to select the less used page, but also those pages that weren’t modified; in this way, the more the system uses a page, the less is the probability for that page to be removed.

When a page present into the main memory is dirty, the system must issue two I/O requests: the former to access the secondary memory for paging it out, the latter to bring the requested page into memory (page in). In this scenario, by analyzing the dirty pages periodically and writing them back to the storage, the algorithm improves the overall performances as well as average access time to memory.

This algorithm suffers the disadvantage of partitioning the main memory in two classes: pages which are frequently accessed and pages less frequently accessed; when searching for target page ends, it’s not assured that the victim page is the oldest, but only one of the less accessed pages.

The best instance happens when the first frame has both R & D bits equal to zero: searching stops immediately and it’s not necessary to page it out.

The worst case happens when all pages are both referenced and modified: in this scenario the MMU must completely scan all the entries, just like a FIFO.

The simulator, written in C, is made up of different entities, which are:

• process: it simulates a user process which can access to an random memory location or issue a I/O read
• i/o device: a dedicated thread is spawn to simulate an i/o device (it comes with a FIFO queue to serve processes requests)
• mmu: the MMU simulates the Memory Management Unit, i.e. the responsible to translate virtual addresses (generated by a user process) into physical address; it’s also implements the second chance algorithm.

It let the user specify how many processes run, how much physical memory is installed, the page size and so on; it requires only a C compiler (like gcc) and the utility Makefile.

Its output is in italian language, even if very simple terms have been used.

Download vmbo.tar.gz

1. Go to the theme directory (DOC_ROOT/wp-contents/themes/yourtheme)
2. Look for file named single.php
3. Look for the template tag named the_content
4. Add a new line below and attach the following istructions:

<?php wp_link_pages(array(‘before’ => ‘<p><strong>Pages:</strong> ‘,’after’ => ‘</p>’, ‘next_or_number’ => ‘number’)); ?>

Try to reload the single post page and enjoy page-links.

For further informations about page-links, read this document.

Archive contains sources and relation, written in italian, which describe the algorithm, its purpose and implementation. This was developed for university purposes.

Download rb-sorter.tar.gz