Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • alexis.durgnat/homepage
  • orestis.malaspin/homepage
2 results
Show changes
Commits on Source (241)
141 additional commits have been omitted to prevent performance issues.
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 124 additions and 5314 deletions
.gitlab-ci.yml
View file @ e029897b
# image: omalaspinas/hakyll-test:latest
image: omalaspinas/pandoc_website:latest
variables:
......@@ -31,8 +32,8 @@ before_script:
build_and_deploy:
script:
- make
- rsync -avzz css ur1bg_malas@ur1bg.ftp.infomaniak.com:web/malaspinas/
- rsync -avzz figs ur1bg_malas@ur1bg.ftp.infomaniak.com:web/malaspinas/
- rsync -avzz index.html ur1bg_malas@ur1bg.ftp.infomaniak.com:web/malaspinas/
- blc https://malaspinas.academy -ro --exclude *.pdf --filter-level 3
- pandoc -v
- make update SHELL=bash
- make deploy SHELL=bash
- rsync -avzz site/* ur1bg_malas@ur1bg.ftp.infomaniak.com:web/malaspinas/
# - blc https://malaspinas.academy/index.html -ro --exclude *.pdf --filter-level 3 --exclude https://bbb.hesge.ch*
Makefile
View file @ e029897b
STYLES := css/tufte-css/tufte.css \
css/pandoc.css \
css/pandoc-solarized.css \
css/tufte-extra.css
all: index.html
all: index.html
index.html: index.md Makefile
pandoc -o $@ $< -t html5 --css css/tufte-css/tufte.css -s
deploy: all
make -C archives
mkdir -p site
mkdir -p site/archives
cp index.html site/
cp -r css site/
cp -r figs site/
cp -r archives/index.html site/archives/
update:
git submodule foreach 'git pull origin master || true'
clean:
rm -rf index.html
rm -rf index.html site
archives/Makefile 0 → 100644
View file @ e029897b
all: index.html
index.html: index.md Makefile
pandoc -o $@ $< -t html5 --css ../css/tufte-css/tufte.css -s
clean:
rm -rf index.html
archives/index.md 0 → 100644
View file @ e029897b
# Cours d'années précédentes
# Physique appliquée
<!-- Chaîne *BBB* du cours <https://bbb.hesge.ch/rooms/ty7-tww-afq-lql/join> -->
---
## [Polycopié](https://malaspinas.academy/phys/index.html), [git repo](https://githepia.hesge.ch/orestis.malaspin/isc_physics), [pdf](https://malaspinas.academy/phys/cours.pdf)
## Exercices sur les Lois de Newton, [HTML](phys/exercices/newton.html), [PDF](phys/exercices/newton.pdf)
## Travail pratique: vecteurs, [HTML](https://malaspinas.academy/phys/practical_work/tp_vec), [PDF](https://malaspinas.academy/phys/practical_work/tp_vec.pdf), [tp_vec2.tar](https://malaspinas.academy/phys/practical_work/tp_vec2.tar)
## Travail pratique: planètes, [HTML](https://malaspinas.academy/phys/planets/enonce.html), [PDF](https://malaspinas.academy/phys/planets/enonce.pdf), [skeleton.tar](https://malaspinas.academy/phys/planets/skeleton.tar)
## Travail pratique: lignes de champs, [HTML](https://malaspinas.academy/phys/field_lines/enonce.html), [PDF](https://malaspinas.academy/phys/field_lines/enonce.pdf), [utils.tar.gz](https://malaspinas.academy/phys/field_lines/utils.tar.gz)
## Travail pratique: circuit RC, [HTML](https://malaspinas.academy/phys/rc_circuit/enonce.html), [PDF](https://malaspinas.academy/phys/rc_circuit/enonce.pdf)
# Mathématiques en technologie de l'information
## [Polycopié](https://malaspinas.academy/mti/index.html), [git repo](https://githepia.hesge.ch/orestis.malaspin/math_tech_info), [pdf](https://malaspinas.academy/mti/cours.pdf)
## [Travail pratique: optimisation](https://malaspinas.academy/mti/tpOptimisation/index.html), [git repo](https://gitedu.hesge.ch/orestis.malaspin/math_tech_info/-/tree/master/travaux_pratiques/tpOptimisation), [pdf](https://malaspinas.academy/mti/tpOptimisation/tpOptimisation.pdf)
## [Travail pratique: intégrales](https://malaspinas.academy/mti/tpIntegrales/index.html), [git repo](https://githepia.hesge.ch/orestis.malaspin/math_tech_info/-/tree/master/travaux_pratiques/tpIntegrales), [pdf](https://malaspinas.academy/mti/tpIntegrales/tp_integrales_conv.pdf)
## [Travail pratique: EDO](https://malaspinas.academy/mti/tpEdo/index.html), [git repo](https://githepia.hesge.ch/orestis.malaspin/math_tech_info/tree/master/tpEdo), [pdf](https://malaspinas.academy/mti/tpEdo/tpEquadiffs.pdf)
# Programmation concurrente (2019-2020)
## [Polycopié](https://malaspinas.academy/concurrence/index.html), [git repo](https://githepia.hesge.ch/orestis.malaspin/cours_prog_conc)
# Exercices de programmation concurrente
## TP1: L'ensemble de Julia [PDF](https://malaspinas.academy/tp_concurrence/julia.pdf), [HTML](https://malaspinas.academy/tp_concurrence/julia.html)
## TP2: Les threads et verrous [PDF](https://malaspinas.academy/tp_concurrence/threads.pdf), [HTML](https://malaspinas.academy/tp_concurrence/threads.html)
## TP3: Structures de données concurrentes [PDF](https://malaspinas.academy/tp_concurrence/synchro.pdf), [HTML](https://malaspinas.academy/tp_concurrence/synchro.html)
## TP4: File et workflow [PDF](https://malaspinas.academy/tp_concurrence/file_workflow.pdf), [HTML](https://malaspinas.academy/tp_concurrence/file_workflow.html)
## TP5: Variables de condition [PDF](https://malaspinas.academy/tp_concurrence/variables_condition.pdf), [HTML](https://malaspinas.academy/tp_concurrence/variables_condition.html)
## Projet: Asteroids [PDF](https://malaspinas.academy/tp_concurrence/asteroids.pdf), [HTML](https://malaspinas.academy/tp_concurrence/asteroids.html)
## TP6: Sémaphores [PDF](https://malaspinas.academy/tp_concurrence/semaphores.pdf), [HTML](https://malaspinas.academy/tp_concurrence/semaphores.html)
## Projet: Asteroids concurrents [PDF](https://malaspinas.academy/tp_concurrence/multithreaded_asteroids.pdf), [HTML](https://malaspinas.academy/tp_concurrence/multithreaded_asteroids.html)
# Anciens exercices en C (2019-20)
## Tableaux unidimensionnels, [HTML](https://malaspinas.academy/prog_seq_c_tp/tableaux_unidimensionnels/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/tableaux_unidimensionnels/tableaux_unidimensionnels.pdf), [GFX](https://malaspinas.academy/prog_seq_c_tp/tableaux_unidimensionnels/gfx_example.tar.gz)
## Les matrices, [HTML](https://malaspinas.academy/prog_seq_c_tp/matrices_intro/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/matrices_intro/matrices_intro.pdf)
## Les chaînes de caractères, [HTML](https://malaspinas.academy/prog_seq_c_tp/chaines_caracteres/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/chaines_caracteres/chaines_caracteres.pdf)
## Traitement d'images, [HTML](https://malaspinas.academy/prog_seq_c_tp/transformations/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/transformations/transformations.pdf)
## Vector, [HTML](https://malaspinas.academy/prog_seq_c_tp/vector/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/vector/vector.pdf)
## Fichier LAS, [HTML](https://malaspinas.academy/prog_seq_c_tp/lidar/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/lidar/read.pdf)
## Fichier STL, [HTML](https://malaspinas.academy/prog_seq_c_tp/stl/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/stl/stl.pdf)
## List-Vector, [HTML](https://malaspinas.academy/prog_seq_c_tp/lst_vector/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/lst_vector/linked_vector.pdf)
## Delaunay, [HTML](https://malaspinas.academy/prog_seq_c_tp/delaunay/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/delaunay/delaunay.pdf)
## TP noté 2: triangulation, [HTML](https://malaspinas.academy/prog_seq_c_tp/lidar_triangulation/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/lidar_triangulation/triangulation.pdf)
## Code Morse, [HTML](https://malaspinas.academy/prog_seq_c_tp/morse/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/morse/morse.pdf)
## Arbres quaternaires, [HTML](https://malaspinas.academy/prog_seq_c_tp/quadtree/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/quadtree/quadtree.pdf)
## File de priorité, [HTML](https://malaspinas.academy/prog_seq_c_tp/priority_queue/index.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/priority_queue/linked_list.pdf)
## Graphes, [HTML](https://malaspinas.academy/prog_seq_c_tp/shortest_path/graphes.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/shortest_path/graphes.pdf), [xml_parser.h](https://malaspinas.academy/prog_seq_c_tp/shortest_path/xml_parser.h), [xml_parser.c](https://malaspinas.academy/prog_seq_c_tp/shortest_path/xml_parser.c), [main.c](https://malaspinas.academy/prog_seq_c_tp/shortest_path/main.c), [villes.xml](https://malaspinas.academy/prog_seq_c_tp/shortest_path/villes.xml), [suisse.txt](https://malaspinas.academy/prog_seq_c_tp/shortest_path/suisse.txt)
## Floyd-Dijkstra, [HTML](https://malaspinas.academy/prog_seq_c_tp/shortest_path/df.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/shortest_path/df.pdf), [squelette.c](https://malaspinas.academy/prog_seq_c_tp/shortest_path/squelette/c/main.c), [Makefile](https://malaspinas.academy/prog_seq_c_tp/shortest_path/squelette/c/Makefile), [commandes_a_tester.txt](https://malaspinas.academy/prog_seq_c_tp/shortest_path/squelette/commandes_de_test/cmd_a_tester.txt), [output](https://malaspinas.academy/prog_seq_c_tp/shortest_path/squelette/results_out/output)
## Tests, [HTML](https://malaspinas.academy/prog_seq_c_tp/shortest_path/test.html), [PDF](https://malaspinas.academy/prog_seq_c_tp/shortest_path/test.pdf)
# Programmation séquentielle en Rust (2018-2019)
* [Slides du cours](https://malaspinas.academy/prog_seq/index.html), [git repo](https://githepia.hesge.ch/orestis.malaspin/rust)
# Exercices programmation séquentielle en Rust (2018-19)
## TP1 Rust: Nombre secret, [HTML](https://malaspinas.academy/prog_seq/exercices/01_nombre_secret/), [PDF](https://malaspinas.academy/prog_seq/exercices/01_nombre_secret/index.pdf)
## TP2 Rust: Calcul de $\pi$, [HTML](https://malaspinas.academy/prog_seq/exercices/02_calcul_pi/), [PDF](https://malaspinas.academy/prog_seq/exercices/02_calcul_pi/index.pdf)
## TP3 Rust: Tableaux, [HTML](https://malaspinas.academy/prog_seq/exercices/03_tableaux/), [PDF](https://malaspinas.academy/prog_seq/exercices/03_tableaux/index.pdf)
## TP4 Rust: Couverture de la reine, [HTML](https://malaspinas.academy/prog_seq/exercices/04_reine/), [PDF](https://malaspinas.academy/prog_seq/exercices/04_reine/index.pdf)
## TP5 Rust: Puissance 4, [HTML](https://malaspinas.academy/prog_seq/exercices/05_puissance4/), [PDF](https://malaspinas.academy/prog_seq/exercices/05_puissance4/index.pdf)
## TP6 Rust: Listes, [HTML](https://malaspinas.academy/prog_seq/exercices/06_listes/), [PDF](https://malaspinas.academy/prog_seq/exercices/06_listes/index.pdf)
## TP7 Rust: Reed-Solomon, [HTML](https://malaspinas.academy/prog_seq/exercices/07_reed_solomon/index.html), [PDF](https://malaspinas.academy/prog_seq/exercices/07_reed_solomon/index.pdf)
## TP8 Rust: Transformation d'images, [HTML](https://malaspinas.academy/prog_seq/exercices/08_transformation_images/index.html), [PDF](https://malaspinas.academy/prog_seq/exercices/08_transformation_images/index.pdf)
## TP9 Rust: Problème du voyageur de commerce, [HTML](https://malaspinas.academy/prog_seq/exercices/09_voyageur_commerce/index.html), [PDF](https://malaspinas.academy/prog_seq/exercices/09_voyageur_commerce/index.pdf)
tufte-css @ e225f3a0
Compare c414b911...e225f3a0
Subproject commit c414b9117d5b39bdb747a172822333fc1043aee3
Subproject commit e225f3a0e5f8f42a1d28416c1c85962411711907
hakyll-bootstrap/.gitignore deleted 100644 → 0
View file @ f2da99ba
dist
cabal-dev
*.o
*.hi
*.chi
*.chs.h
*.swp
_cache
_site
cabal.sandbox.config
.cabal-sandbox/
.stack-work
hakyll-bootstrap/LICENSE deleted 100644 → 0
View file @ f2da99ba
The MIT License (MIT)
Copyright (c) 2013-2017 Stephen Diehl
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
hakyll-bootstrap/Main.hs deleted 100644 → 0
View file @ f2da99ba
{-# LANGUAGE OverloadedStrings #-}
--------------------------------------------------------------------
-- |
-- Copyright : (c) Stephen Diehl 2013
-- License : MIT
-- Maintainer: stephen.m.diehl@gmail.com
-- Stability : experimental
-- Portability: non-portable
--
--------------------------------------------------------------------
module Main where
{-# LANGUAGE OverloadedStrings #-}
import Data.Monoid (mappend)
import Hakyll
import Text.Pandoc
import qualified Data.Map as M
import Data.Maybe (isJust)
import Text.Pandoc.Highlighting
import Hakyll.Images ( loadImage
, scaleImageCompiler
)
--------------------------------------------------------------------
-- Contexts
--------------------------------------------------------------------
postCtx :: Context String
postCtx =
dateField "date" "%B %e, %Y"
`mappend` mathCtx
`mappend` defaultContext
mathCtx :: Context String
mathCtx = field "mathjax" $ \item -> do
metadata <- getMetadata $ itemIdentifier item
return ""
return $ if isJust $ lookupString "mathjax" metadata
then "<script type=\"text/javascript\" src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_HTML\"></script>"
else ""
archiveCtx posts =
listField "posts" postCtx (return posts)
`mappend` constField "title" "Archives"
`mappend` defaultContext
indexCtx posts =
listField "posts" postCtx (return posts)
`mappend` constField "title" "Home"
`mappend` defaultContext
--------------------------------------------------------------------
-- Rules
--------------------------------------------------------------------
static :: Rules ()
static = do
match "fonts/*" $ do
route idRoute
compile $ copyFileCompiler
match "img/*" $ do
route idRoute
compile $ copyFileCompiler
match "css/*" $ do
route idRoute
compile compressCssCompiler
match "js/*" $ do
route idRoute
compile $ copyFileCompiler
resize :: Rules ()
resize = do
match "img/**.png" $ do
route idRoute
compile $ loadImage
>>= scaleImageCompiler 140 140
pages :: Rules ()
pages = do
match "pages/*" $ do
route $ setExtension "html"
compile $ getResourceBody
>>= loadAndApplyTemplate "templates/page.html" postCtx
>>= relativizeUrls
posts :: Rules ()
posts = do
match "posts/*" $ do
route $ setExtension "html"
-- compile $ myPandocCompiler
compile $ bibtexCompiler
>>= loadAndApplyTemplate "templates/post.html" postCtx
>>= relativizeUrls
archive :: Rules ()
archive = do
create ["archive.html"] $ do
route idRoute
compile $ do
posts <- recentFirst =<< loadAll "posts/*"
makeItem ""
>>= loadAndApplyTemplate "templates/archive.html" (archiveCtx posts)
>>= relativizeUrls
cours :: Rules ()
cours = do
match "cours/*" $ do
route $ setExtension "html"
-- compile $ myPandocCompiler
compile $ bibtexCompiler
>>= loadAndApplyTemplate "templates/post.html" postCtx
>>= relativizeUrls
conc :: Rules ()
conc = do
create ["prog_conc.html"] $ do
route idRoute
compile $ do
posts <- recentFirst =<< loadAll "cours/*"
makeItem ""
>>= loadAndApplyTemplate "templates/archive.html" (archiveCtx posts)
>>= relativizeUrls
index :: Rules ()
index = do
match "index.html" $ do
route idRoute
compile $ do
posts <- recentFirst =<< loadAll "posts/*"
getResourceBody
>>= applyAsTemplate (indexCtx posts)
>>= relativizeUrls
templates :: Rules ()
templates = match "templates/*" $ compile templateCompiler
--------------------------------------------------------------------
-- Configuration
--------------------------------------------------------------------
myPandocCompiler :: Compiler (Item String)
myPandocCompiler = pandocCompilerWith defaultHakyllReaderOptions pandocOptions
pandocOptions :: WriterOptions
pandocOptions = defaultHakyllWriterOptions
{
writerExtensions = defaultPandocExtensions
, writerHTMLMathMethod = MathJax ""
}
-- Pandoc extensions used by the myPandocCompiler
defaultPandocExtensions :: Extensions
defaultPandocExtensions =
let extensions = [
-- Pandoc Extensions: http://pandoc.org/MANUAL.html#extensions
-- Math extensions
Ext_tex_math_dollars
, Ext_tex_math_double_backslash
, Ext_latex_macros
-- Code extensions
, Ext_fenced_code_blocks
, Ext_backtick_code_blocks
, Ext_fenced_code_attributes
, Ext_inline_code_attributes -- Inline code attributes (e.g. `<$>`{.haskell})
-- Markdown extensions
, Ext_implicit_header_references -- We also allow implicit header references (instead of inserting <a> tags)
, Ext_definition_lists -- Definition lists based on PHP Markdown
, Ext_yaml_metadata_block -- Allow metadata to be speficied by YAML syntax
, Ext_superscript -- Superscripts (2^10^ is 1024)
, Ext_subscript -- Subscripts (H~2~O is water)
, Ext_footnotes -- Footnotes ([^1]: Here is a footnote)
]
defaultExtensions = writerExtensions defaultHakyllWriterOptions
in foldr enableExtension defaultExtensions extensions
bibtexCompiler :: Compiler (Item String)
bibtexCompiler = do
getResourceBody
>>= withItemBody (unixFilter "pandoc" ["-F"
, "pandoc-numbering"
, "-F"
, "pandoc-crossref"
, "-t"
, "markdown"
])
>>= readPandocWith defaultHakyllReaderOptions
>>= return . writePandocWith pandocOptions
cfg :: Configuration
cfg = defaultConfiguration
main :: IO ()
main = hakyllWith cfg $ do
pages
posts
cours
conc
archive
index
templates
static
hakyll-bootstrap/README.md deleted 100644 → 0
View file @ f2da99ba
hakyll-bootstrap
================
<p align="center" style="padding: 20px; width: 50%">
<img src="https://raw.github.com/sdiehl/hakyll-bootstrap/master/sample.png">
</p>
A template for a small corporate Hakyll site.
**Using stack**
```bash
$ stack build
$ stack exec blog -- preview
```
**Using cabal**
To get started run:
```shell
$ cabal sandbox init
$ cabal install --only-dependencies
$ cabal run preview
```
The default static pages are renderd with plain HTML with mixins
from the ``/templates`` folder..
```
index.html
pages/
about.html
contact.html
privacy.html
signup.html
team.html
tos.html
```
Blog posts are placed under the ``/posts`` folder and are
generated from Markdown.
Inline math is enabled via setting the ``mathjax`` metadata to
``on``, by default MathJax is disabled.
```text
---
title: Example Blog Post
author: Stephen Diehl
date: 2013-11-13
mathjax: on
---
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam
non est in neque luctus eleifend. Sed tincidunt vestibulum
facilisis. Aenean ut pulvinar massa.
```
License
--------
Released under MIT License.
hakyll-bootstrap/Setup.hs deleted 100644 → 0
View file @ f2da99ba
import Distribution.Simple
main = defaultMain
hakyll-bootstrap/cours/bugs.md deleted 100644 → 0
View file @ f2da99ba
This diff is collapsed.
hakyll-bootstrap/cours/cond_var.md deleted 100644 → 0
View file @ f2da99ba
This diff is collapsed.
hakyll-bootstrap/cours/intro_api.md deleted 100644 → 0
View file @ f2da99ba
This diff is collapsed.
hakyll-bootstrap/cours/intro_os.md deleted 100644 → 0
View file @ f2da99ba
---
author:
- Orestis Malaspinas, Steven Liatti
title: Introduction vague aux systèmes d'exploitation
autoSectionLabels: false
autoEqnLabels: true
eqnPrefix:
- "éq."
- "éqs."
chapters: true
numberSections: false
chaptersDepth: 1
sectionsDepth: 3
lang: fr
documentclass: article
papersize: A4
cref: false
urlcolor: blue
toc: false
mathjax: on
date: 2020-01-01
---
# Avant-propos
Ce chapitre est fortement inspiré du cours en ligne *Introduction to Operating Systems* se trouvant sur [https://classroom.udacity.com/courses/ud923](https://classroom.udacity.com/courses/ud923).
# Généralités sur les systèmes d'exploitation
Dans ce chapitre, nous allons brièvement introduire ce qu'est un système d'exploitation (ou Operating System, abrégé OS, en anglais)
et comment il fait fonctionner un ordinateur. Mais avant de donner une
vague définition de ce qu'est un système d'exploitation,
nous allons d'abord rappeler en quoi consiste un ordinateur.
Un ordinateur est constitué de plusieurs composants: un ou plusieurs processeurs (ou Central Processing Units, abrégé CPU, en anglais) qui
peut contenir plusieurs cœurs, de la mémoire, une carte réseau ou wifi,
une carte graphique, un disque dur, des périphériques USB, ...
Tous ces composants seront utilisés par une ou plusieurs applications
(le butineur, le lecteur multimédia, l'éditeur de texte,
Dota 2, ...).
## Qu'est-ce qu'un système d'exploitation?
Le système d'exploitation est une couche de logiciel qui fait le lien entre les applications et les différents composants matériel
d'un ordinateur. Il n'existe pas de définition unique de ce qu'est un système
d'exploitation. Nous allons plutôt le définir ici par les tâches qu'il est capable
d'effectuer:
0. A un accès privilégié direct au matériel.
1. Il cache la complexité du matériel à l'utilisateur et aux développeurs d'applications.
2. Il gère les ressources matérielles. Quelle application peut utiliser quelle ressource et à quel moment elle peut le faire (leur ordonnancement).
3. Il isole et protège les ressources. Il empêche que plusieurs applications utilisent les mêmes parties des ressources au même moment. En particulier, différentes applications n'ont pas accès à la même partie de la mémoire en même temps.
---
Exemple #
Lorsqu'on lit ou on écrit de la musique sur une mémoire USB et le disque dur d'un ordinateur, à aucun moment il y a besoin de réfléchir où exactement sur le disque, nous allons écrire/lire les bits des fichiers.
Il empêche qu'un fichier soit écrasé sans que l'utilisateur le veuille.
De plus, il n'y a pas de différence notable entre les deux pour un utilisateur
alors que le chemin pour accéder à l'un ou à l'autre est très différent.
De plus, à aucun moment il n'y a besoin d'ordonnancer les différentes applications sur le processeur. Toutes ces opérations complexes sont effectuées pour nous par le système d'exploitation.
---
Quels systèmes d'exploitation connaissez-vous?
1. Windows.
2. Mac-OS (BSD), Linux: basé sur Unix.
3. Android.
4. iOS.
5. ....
Dans cette introduction, on va plutôt discuter les systèmes Linux.
---
Quiz #
Choisissez parmi les possibilités suivantes quels sont les différents composants d'un système d'exploitation:
1. Un éditeur de fichier.
2. Un système de fichier.
3. Un driver de carte graphique.
4. La mémoire cache.
5. Un compilateur.
6. Un ordonnanceur.
---
## De quoi est constitué un système d'exploitation
Il y a trois concepts de base qui constituent un système d'exploitation.
1. Les abstractions: comme les processus, les fils d'exécution (ou threads), les fichiers, les socket, les pages mémoire, ...
2. Les mécanismes: la création, l'ordonnancement des processus/threads, lire/écrire dans dans un fichier, allouer/désallouer de la mémoire, ...
3. Les politiques: qui déterminent comment les mécanismes vont utilisent les abstractions du matériel sous jacent.
---
Exemple #
Afin de gérer de la mémoire, le système d'exploitation utilise **l'abstraction** de la page mémoire. Une page mémoire correspond à
une adresse de taille fixe (4kb par exemple). Le système d'exploitation
va également avoir des **mécanismes** pour interagir avec cette page:
allouer la page dans la mémoire, ou la maper dans l'espace d'adressage d'un processus pour qu'il puisse accéder à ce qu'il y a dans cette page mémoire. Cette page peut être déplacée dans la mémoire ou même sur le disque dur s'il y a besoin de faire de la place dans la mémoire (swapping).
Ces dernières actions sont basées sur la **politique** du système d'exploitation. Une façon de décider si une page doit être copiée sur le disque dur peut être de prendre la page qui a été utilisée le moins récemment.
---
## Mécanismes de protection d'un système d'exploitation
Le système d'exploitation doit contrôler et gérer les ressources matérielles d'un ordinateur.
Pour ce faire il doit avoir des **privilèges** particuliers pour accéder aux différents composants.
Il y a deux modes principaux d'accès au matériel:
1. Le mode utilisateur (sans privilèges).
2. Le mode "noyau" (avec privilèges).
Le système d'exploitation opère évidemment en mode noyau, alors que les
applications (processus) eux opèrent en mode utilisateur. Il existe une
barrière ne permettant pas aux applications d'effectuer
des opérations privilégiées sur le matériel, seul le système d'exploitation
peut les effectuer. Cette barrière est directement supportée par les matériel. En fait, si un processus tente d'effectuer directement
une opération réservée au mode noyau, la tentative sera capturée et
la main sera passée au système d'exploitation pour gérer ce qu'il convient de faire. Afin qu'une application puisse effectuer
une opération privilégiée elle doit passer au travers du système d'exploitation, via un **appel système**. Un appel système est une interface qu'expose le système d'exploitation afin de permettre aux
processus d'effectuer de demander au système d'exploitation d'effectuer
une opération privilégiée pour eux. Par exemple, `open(file)`{.language-c} pour ouvrir un fichier,
`mmap(memory)`{.language-c} pour allouer de la mémoire, créer un fil d'exécution, ...
# Résumé
Dans ce chapitre, nous avons très brièvement discuté ce qu'est un système d'exploitation.
Il permet de cacher la complexité du matériel aux applications en mettant en place des abstractions
et des mécanismes qui permettent de contrôler le matériel et de protéger
les applications entre elles, et de les isoler. De plus il sert à gérer les différentes
applications qui sont exécutées sur un ordinateur.
Dans le chapitre suivant, nous allons voir ce qu'est plus en détail une application (ou processus)
et comment différents processus sont gérés par le système d'exploitation.
\ No newline at end of file
hakyll-bootstrap/cours/intro_processus.md deleted 100644 → 0
View file @ f2da99ba
This diff is collapsed.
hakyll-bootstrap/cours/sema.md deleted 100644 → 0
View file @ f2da99ba
This diff is collapsed.
hakyll-bootstrap/cours/structures_conc.md deleted 100644 → 0
View file @ f2da99ba
---
author:
- Orestis Malaspinas, Steven Liatti
title: Structures de données concurrentes
autoSectionLabels: false
autoEqnLabels: true
eqnPrefix:
- "éq."
- "éqs."
chapters: true
numberSections: false
chaptersDepth: 1
sectionsDepth: 3
lang: fr
documentclass: article
papersize: A4
cref: false
urlcolor: blue
toc: false
date: 2020-01-01
mathjax: on
include-before: <script src="css/prism.js"></script>
---
# Les structures de données basées sur les verrous
Le contenu de ce chapitre est basé sur l'excellent livre de R. H. Arpaci-Dusseau et A. C. Arpaci-Dusseau[^3].
Dans ce chapitre, nous allons brièvement voir comment utiliser des verrous
dans des structures de données standards de façon à ce qu'elles soient
sûres à l'utilisation dans des applications multi-threadées.
La difficulté principale est de garder une bonne performance tout en garantissant un fonctionnement correct.
## Les compteurs concurrents
La structure de données la plus simple qu'on puisse imaginer est un simple
compteur. Nous avons déjà vu dans les exercices comment incrémenter
de façon fausse un compteur de façon concurrente, puis une façon juste mais peu efficace. Histoire de formaliser tout ceci un peu ici,
écrivons un compteur atomique dans la structure `counter_t`{.language-c}
ainsi que les opérations d'incrémentation et de décrémentation.
```language-c
typedef struct __counter_t {
int value; // la valeur du compteur
pthread_mutex_t lock; // le mutex protégeant le compteur
} counter_t;
void init(counter_t *cnt) {
cnt->value = 0;
pthread_mutex_init(&cnt->lock, NULL);
}
void increment(counter_t *cnt) {
pthread_mutex_lock(&cnt->lock);
cnt->value += 1;
pthread_mutex_unlock(&cnt->lock);
}
void decrement(counter_t *cnt) {
pthread_mutex_lock(&cnt->lock);
cnt->value -= 1;
pthread_mutex_unlock(&cnt->lock);
}
int get_value(counter_t *cnt) {
pthread_mutex_lock(&cnt->lock);
int value = cnt->value;
pthread_mutex_unlock(&cnt->lock);
return value;
}
```
Ici, nous avons rendues atomiques les opérations d'incrémentation, de décrémentation et de retour de la valeur du compteur en protégeant les
sections critiques (d'incrémentation, de décrémentation et du compteur)
à l'aide de verrous. Notre structure de données est donc parfaitement
concurrente et fonctionne correctement. Néanmoins, on peut assez facilement
se rendre compte que cette méthode peut souffrir d'un problème de performances. Néanmoins, on a ici une méthode très très simple
de rendre une structure de données concurrente: ajouter un verrou!
Pour rendre ces structures plus efficaces, il faut utiliser la ruse.
Pour illustrer le problème de performances d'un code n'utilisant
qu'un simple verrou, on peut s'intéresser à la performance du code de l'incrémentation de notre compteur un million de fois. Si on mesure le temps d'exécution du code sur un, deux ou quatre fils d'exécution,
on obtient le tableau ci-dessous :
| | 1 thread | 2 threads | 4 threads |
| --------------|:--------------:|:---------------:|:--------------:|
| Temps $[ms]$ | 0.031 | 0.149 | 0.447 |
On voit un ralentissement assez spectaculaire de l'exécution (plus d'un facteur 10) entre le cas à un seul thread et le cas à 4 threads. Ici,
la quantité de travail à effectuer étant constante par processeur (chaque
CPU devait incrémenter un million de fois la variable) on aimerait que
le temps total reste constant (ce qui serait une **mise à l'échelle parfaite**, ou **perfect scaling**).
Différentes approches pour résoudre ce problème ont été proposées. Ici, nous allons étudier celle du **approximate counter**. L'idée générale
est d'avoir **plusieurs** compteurs logiques locaux (un par CPU) et un compteur **global**. On aura en plus un verrou **local** par CPU,
lié aux compteurs locaux (celui-ci n'est nécessaire qu'en cas d'exécution de plusieurs
threads par CPU), un verrou **global** pour le compteur global.
On va incrémenter "localement" tous les compteurs des CPUs qui se synchroniseront
avec leurs verrous locaux respectifs. Comme les threads dans leurs CPUs respectifs
peuvent incrémenter leurs compteurs sans contention, la mise à l'échelle
sera bonne. Néanmoins, il est nécessaire de synchroniser les
compteurs entre les CPUs afin de pouvoir lire la valeur du compteur
si nécessaire. On devra donc périodiquement transférer les valeurs
des compteurs locaux au compteur global de temps en temps,
en additionnant tous les compteurs locaux au compteur global.
A ce moment là les compteurs locaux seront remis à zéro.
Le moment où les compteurs locaux seront synchronisés dépendra d'une variable, $s$. Plus $s$ sera grand, moins la valeur stockée dans $s$ sera précise (plus il y aura de chances qu'elle ne contienne pas la bonne valeur), mais plus le calcul aura une bonne performance sur plusieurs threads. A l'inverse un petit $s$ aura de moins bonnes performances, mais
donnera une valeur plus correcte du compteur.
Considérons un exemple où on a 4 threads $T_1$-$T_4$, avec quatre compteurs locaux $L_1$ à $L_4$, et où $s=4$.
Un exemple d'exécution est résumé dans la table ci-dessous
| Temps | $L_1$ | $L_2$ | $L_3$ | $L_4$ | $G$ |
| --------------|:--------------:|:--------------:|:--------------:|:--------------:|:--------------:|
| 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | 1 | 0 | 1 | 1 | 0 |
| 2 | 2 | 0 | 1 | 2 | 0 |
| 3 | 3 | 1 | 1 | 3 | 0 |
| 4 | 4 | 1 | 2 | $4\rightarrow 0$ | 4 (de $L_4$) |
| 5 | $4\rightarrow 0$ | 2 | 3 | 0 | 8 (de $L_1$) |
Les compteurs locaux s'incrémentent chacun à leur vitesse, mais lorsqu'un d'entre eux atteint $s=4$, sa valeur
est ajoutée au compteur global $G$, et il est remis à zéro. On voit donc pourquoi
la valeur est approximée. Au temps 5, le compteur
a été incrémenté 13 fois, hors la valeur que nous pouvons lire
dans le compteur global est de huit uniquement.
On peut à présent écrire le code suivant pour le compteur approximé :
```language-c
typedef struct __approx_counter_t {
int glob_counter; // global counter
pthread_mutex_t glob_mutex; // global mutex
int *local_counter; // local counter array
int threshold; // threshold where we communicate
} approx_counter_t;
void init(approx_counter_t *ac, int threshold) {
ac->threshold = threshold;
ac->glob_counter = 0;
pthread_mutex_init(&ac->glob_mutex, NULL);
ac->local_counter = malloc(num_threads * sizeof(int));
ac->local_mutex = malloc(num_threads * sizeof(pthread_mutex_t));
for (int i = 0; i < num_threads; ++i) {
ac->local_counter[i] = 0;
pthread_mutex_init(&ac->local_mutex[i], NULL);
}
}
void increment_by(approx_counter_t *ac, int tid, int amount) {
ac->local_counter[tid] += amount;
if (ac->local_counter[tid] >= ac->threshold) {
pthread_mutex_lock(&ac->glob_mutex); // verrou global
ac->glob_counter += ac->local_counter[tid];
pthread_mutex_unlock(&ac->glob_mutex); // fin verrou global
ac->local_counter[tid] = 0;
}
}
int get_counter(approx_counter_t *ac) {
pthread_mutex_lock(&ac->glob_mutex);
int value = ac->glob_counter;
pthread_mutex_unlock(&ac->glob_mutex);
return value;
}
```
Il faut noter que dans notre structure `approx_counter_t`{.language-c}
nous n'avons pas utilisé de verrou local. On suppose ici par simplicité qu'il n'y a qu'un thread par cœur.
On peut à présent mesurer la performance de ce compteur pour un $s$ donné si on incrémente un million de fois un compteur sur un à quatre threads.
| | 1 thread | 2 thread | 4 thread |
| --------------|:--------------:|:--------------:|:--------------:|
| Temps, $s=1$, $[ms]$ | 0.053 | 0.36 | 0.69 |
| Temps, $s=10$, $[ms]$ | 0.012 | 0.044 | 0.086 |
| Temps, $s=100$, $[ms]$ | 0.008 | 0.018 | 0.032 |
| Temps, $s=1000$, $[ms]$ | 0.009 | 0.01 | 0.012 |
## La liste chaînée concurrente
Une liste chaînée est une structure de données où un élément de notre
liste contient une valeur, ainsi qu'un pointeur vers le prochain
élément de la liste (vous avez déjà vu ces choses là en première).
Un petit code tout simple implémentant
l'insertion en tête de la liste d'un élément
entier peut s'écrire de la façon suivante, ainsi qu'une
fonction permettant de déterminer si un élément est bien présent
dans votre liste peut se trouver ci-dessous :
```language-c
typedef struct __node_t {
int key;
struct __node_t *next;
} node_t;
typedef struct __list_t {
node_t *head;
} list_t;
void init(list_t *l) {
l->head = NULL;
}
int insert(list_t *l, int key) {
node_t *new = malloc(sizeof(node_t));
if (new == NULL) {
printf("Malloc failed.\n");
return -1;
}
new->key = key;
l->head = new;
return 0;
}
int lookup(list_t *l, int key) {
node_t *current = l->head;
while (current) {
if (current->key) {
return 0;
}
current = current->next;
}
return -1;
}
```
Il est évident qu'avec ce petit bout de code il est impossible
d'insérer et de vérifier la présence ou non d'un élément dans notre
liste de façon concurrente.
On veut à présent réécrire ce code pour qu'il soit utilisable dans une application multi-threadée. La première approche serait de protéger
le moment de l'insertion, ainsi que la lecture par un verrou
qui serait intégré dans notre structure `list_t`. Le code deviendrait
```language-c
typedef struct __node_t {
int key;
struct __node_t *next;
} node_t;
typedef struct __list_t {
node_t *head;
pthread_mutex_t mutex;
} list_t;
void init(list_t *l) {
l->head = NULL;
pthread_mutex_init(&l->mutex, NULL);
}
int insert(list_t *l, int key) { // on retourne vrai si tout s'est bien passé
pthread_mutex_lock(&l->mutex); // début de la section critique
node_t *new = malloc(sizeof(node_t));
if (new == NULL) {
printf("Malloc failed.\n");
pthread_mutex_unlock(&l->mutex); // fin de la section critique
return -1; // error
}
new->key = key;
new->next = l->head;
l->head = new;
pthread_mutex_unlock(&l->mutex); // fin de la section critique
return 0; // success
}
int lookup(list_t *l, int key) {
pthread_mutex_lock(&l->mutex); // début de la section critique
node_t *current = l->head;
while (current) {
if (current->key == key) {
pthread_mutex_unlock(&l->mutex); // autre fin de la section critique
return 0;
}
current = current->next;
}
pthread_mutex_unlock(&l->mutex); // autre fin de la section critique
return -1;
}
```
Regardons d'abord la fonction `lookup()`{.language-c}. On constate
qu'au tout début on `lock()`{.language-c} notre verrou, afin de protéger la
partie où on va vérifier si un élément est présent ou non dans notre
liste. Il faut en effet être certain·e·s qu'aucun nouvel élément n'est
ajouté pendant que nous lisons, car cela pourrait avoir des effets dramatiques[^1]. Le verrou est libéré non seulement lorsqu'on a trouvé
l'élément `key`{.language-c} mais également lorsqu'il est absent:
il y a deux endroits distincts où il faut penser à faire un `unlock()`{.language-c}. En effet, il faut libérer le verrou **avant** de sortir
de la fonction sinon le verrou ne sera jamais déverrouillé...
La fonction `insert()`{.language-c} verrouille le `mutex`{.language-c}, crée l'élément suivant dans la liste et l'insère en tête
avant de déverrouiller le `mutex`{.language-c}. Rien de très fou. Néanmoins, il faut remarquer
que le verrou doit être libéré dans le cas où `malloc()`{.language-c}
retourne une erreur. Bien que cela ne se produise pas souvent,
ce cas peut conduire à des threads qui attendent indéfiniment
après une erreur d'allocation. De façon générale,
il faut être prudent·e lorsqu'on a des branchement conditionnels
qui modifient l'exécution d'un programme. Souvent c'est
dans ce genre de branchement que se trouvent les erreurs
les plus difficiles à détecter.
Cette façon d'écrire une liste chaînée concurrente
est simple, mais nous utilisons trop de branchements conditionnels
ce qui augmente les chances d'introduire des erreurs.
Il est possible de modifier légèrement le code
afin d'avoir un plus petit nombre de chemins
possibles pour le code, réduisant le nombre de libérations
de verrous à effectuer :
```language-c
void init(list_t *l) {
l->head = NULL;
pthread_mutex_init(&l->mutex, NULL);
}
void insert(list_t *l, int key) { // on retourne vrai si tout s'est bien passé
node_t *new = malloc(sizeof(node_t)); // malloc est thread safe
if (new == NULL) {
printf("Malloc failed.\n");
return; // error
}
new->key = key;
pthread_mutex_lock(&l->mutex); // début de la section critique
new->next = l->head;
l->head = new;
pthread_mutex_unlock(&l->mutex); // fin de la section critique
}
int lookup(list_t *l, int key) {
int ret_val = -1;
pthread_mutex_lock(&l->mutex); // début de la section critique
node_t *current = l->head;
while (current) {
if (current->key == key) {
ret_val = 0;
break;
}
current = current->next;
}
pthread_mutex_unlock(&l->mutex); // fin de la section critique
return ret_val;
}
```
Ici, nous constatons que nous avons simplement enlevé
l'acquisition du verrou devant `malloc()`{.language-c}.
Cela est possible, car `malloc()`{.language-c} est *thread-safe*.
Nous n'avons besoin de verrouiller que lorsqu'on écrit ou qu'on
lit dans la liste. Par ailleurs, en ne retournant qu'une seule fois
depuis `lookup()`{.language-c}, on s'affranchit
de déverrouiller une fois supplémentaire.
Ce genre de liste chaînée n'a pas une grande efficacité
lorsqu'on augmente le nombre de threads. Néanmoins, nous n'avons pas réussi
à faire beaucoup mieux. Une technique explorée par les chercheurs
a été le "hand-over-hand locking". L'idée est la suivante. Au lieu
d'avoir un seul verrou pour toute la liste chaînée,
on a un verrou par noeud. Lorsqu'on parcourt la liste,
on acquière d'abord le verrou du nœud suivant et libère le
verrou du nœud courant. Ainsi, la liste peut être parcourue de façon
concurrente. Néanmoins, le coût de verrouillage/déverrouillage
rend cette façon de faire moins efficace en pratique.
## La file concurrente
De façon similaire à ce que nous avons fait jusque là, nous
allons écrire une file concurrente. Faites si vous voulez
la partie simple consistant à écrire une file séquentielle,
puis à la rendre concurrente à l'aide d'un verrou
de la façon la plus triviale possible. Ici, nous allons
étudier un algorithme proposé par Michael et Scott[^2].
Un code reproduisant leur idée se trouve ci-dessous :
```{.language-c}
typedef struct __node_t {
int value;
struct __node_t *next;
} node_t;
typedef struct __queue_t {
node_t *head;
node_t *tail;
pthread_mutex_t head_lock;
pthread_mutex_t tail_lock;
} queue_t;
void init(queue_t *q) {
node_t *tmp = malloc(sizeof(node_t));
tmp->next = NULL;
q->head = q->tail = tmp;
pthread_mutex_init(&q->head_lock, NULL);
pthread_mutex_init(&q->tail_lock, NULL);
}
void enqueue(queue_t *q, int value) {
node_t *tmp = malloc(sizeof(node_t));
assert(tmp != NULL);
tmp->value = value;
tmp->next = NULL;
pthread_mutex_lock(&q->tail_lock);
q->tail->next = tmp;
q->tail = tmp;
pthread_mutex_unlock(&q->tail_lock);
}
int dequeue(queue_t *q, int *value) {
pthread_mutex_lock(&q->head_lock);
node_t *tmp = q->head;
node_t *newHead = tmp->next;
if (newHead == NULL) {
pthread_mutex_unlock(&q->head_lock); // attention branchement
return -1; // queue was empty
}
*value = newHead->value;
q->head = newHead;
pthread_mutex_unlock(&q->head_lock); // attention branchement
free(tmp);
return 0;
}
```
Dans ce code, on constate qu'il y a deux verrous: un pour la queue et un
pour la tête. On peut ainsi avoir une approche suffisamment fine pour
enfiler ou défiler de façon concurrente (les deux opérations
ne sont pas mutuellement exclusives). Cela est rendu possible
par la création d'un nœud fictif lors de la création de la file.
Sans lui les fonction `enqueue()`{.language-c} et `dequeue()`{.language-c}
ne pourraient avoir lieu de façon concurrente.
## La table de hachage concurrente
A l'aide de la liste concurrente que nous avons implémenté tout à l'heure,
il est très simple de créer une table de hachage concurrente (très simple)
concurrente: elle sera statique.
```language-c
#define BUCKETS (101)
typedef struct __hash_t {
list_t lists[BUCKETS];
} hash_t;
void init(hash_t *h) {
for (int i = 0; i < BUCKETS; i++) {
list_init(&h->lists[i]);
}
}
int insert(hash_t *h, int key) {
int bucket = key % BUCKETS;
return list_insert(&h->lists[bucket], key);
}
int lookup(hash_t *h, int key) {
int bucket = key % BUCKETS;
return list_lookup(&H->lists[bucket], key);
}
```
On constate que cette table de hachage ne nécessite aucun nouveau verrou.
Toutes les sections critiques sont cachées dans les fonctions
de la liste chaînée. En effet, la table de hachage n'est
rien d'autre qu'un tableau de listes chaînées dans le cas
simple où le nombre d'alvéoles est statique.
---
Exercice #
Implémenter la table de hachage dynamique.
---
[^1]: Plusieurs bébés chats sont morts à la suite de lectures non protégées de listes concurrentes.
[^2]: M. Michael, M. Scott, *Nonblocking Algorithms and Preemption-safe Locking on by Multiprogrammed Shared-memory Multiprocessors* *Journal of Parallel and Distributed Computing*, **51**, No. 1, (1998).
[^3]: R. H. Arpaci-Dusseau et A. C. Arpaci-Dusseau, *Operating Systems: Three Easy Pieces*, Arpaci-Dusseau Books, ed. 0.91, (2015).
\ No newline at end of file
hakyll-bootstrap/cours/verrous.md deleted 100644 → 0
View file @ f2da99ba
This diff is collapsed.
hakyll-bootstrap/css/bootstrap-theme.css deleted 100644 → 0
View file @ f2da99ba
This diff is collapsed.
hakyll-bootstrap/css/bootstrap-theme.min.css deleted 100644 → 0
View file @ f2da99ba
This diff is collapsed.