Discussion :

[je®ome]

Bonsoir,

je cherche à exécuter un bout de code en section critique.

Qu'y a-t-il de similaire à un CLI et un STI (asm) ?
J'obtiens un segfault si je met directement ces instructions en asm.
D'après différentes docs sur le net, c'est parce qu'on a uniquement le droit en mode kernel et non user.

J'ai trouvé spinlock ou encore lock_kernel, mais je ne trouve pas les fichiers d'entêtes correspondants.


Quelqu'un a une idée comment procéder ?
Merci d'avance pour toute aide ...

[Gruik]

Salut,

Pourquoi ne pas utiliser les threads?

[je®ome]

Salut,

Pourquoi ne pas utiliser les threads?

Je veux garantir cette suite d'instruction dans un programme sans threads.
Dans le cas d'un driver, aucun thread n'est utilisé pour les sections critiques ...

[ram-0000]

Je veux garantir cette suite d'instruction dans un programme sans threads.
Dans le cas d'un driver, aucun thread n'est utilisé pour les sections critiques ...

Je ne comprends pas bien ton problème.

Pour les section critiques, en général, tu veux garantir un accès exclusif à une ressource (mémoire, fichier, périphérique, code, ...) vis a vis d'un programme/processus/thread concurrent qui pourrait vouloir faire la même chose.

Dans ton cas, tes concurrents ils sont où ? Est ce que tu peux expliquer un peu plus ton problème ?

Les instructions STI/CLI sont des instructions assembleurs qui nécessitent des privilèges (ring0) mais surtout qui empêchent les interruptions. A ce propos, je ne suis pas sûr que le fait de masquer les interruptions empêche le scheduler de faire un changement de tâche et donc, ce n'est peut être pas la solution à ton problème.

[je®ome]

Les concurrents sont toutes les autres tâches linux qui tournent sur l'os.
En stoppant les irq, je suis certain de stopper le scheduler, car le scheduler utilise l'interruption timer (irq0).

Sinon, comment exécuter un programme en mode kernel ? ( sans faire de module driver)

Merci pour l'intérêt porté à mon problème !!

[ram-0000]

Et pourquoi alors ne pas utiliser un sémaphore. C'est un peu prévu pour tout de même. Regarde du côté de semget().

Et puis stopper le schéduler, c'est probablement pas une bonne idée.

[Médinoc]

Les concurrents sont toutes les autres tâches linux qui tournent sur l'os.

Attends, quel genre de ressources cherches-tu à exploiter là?

Sur un OS moderne, très peu de choses sensées ont besoin d'un accès exclusif au processeur...

Pour ça, je dirais que la méthode la plus simple est d'utiliser nice() pour récupérer la priorité la plus absolue, ainsi tu passeras "devant" les autres processus.
Mais à mon avis, ça ne te permettra pas de passer devant les drivers, ni complètement devant les autres programmes s'il y a un mécanisme anti-famine comme sous Windows...

[je®ome]

Merci pour vos réponses.

@ram-0000:
une sémaphore permet de contrôler l'accès d'une zone mémoire partagée entre différents threads et processus. Ce n'est pas ce que je cherche à faire.

@Médinoc:
Il faut que je garantisse le temps d'écriture sur le port parallèle,car j'envoi un signal via ce port et que le signal est faussé à cause du switching de tâche.

Pour ceux que ça intéresse, je n'ai pas continuer à chercher, mais ai écrit un petit module kernel. J'utilise les fonctions lock_kernel et unlock_kernel afin d'éviter le switching de tâche pendant ma section critique. J'atteint ainsi une stabilité de 98% sur mon signal contre 75% avant l'utilisation du module.

[Emmanuel Delahaye]

Il faut que je garantisse le temps d'écriture sur le port parallèle,car j'envoi un signal via ce port et que le signal est faussé à cause du switching de tâche.

Problème de conception. Un PC n'est pas une base de temps. Tu ne pourras jamais avoir un signal vraiment stable sur un port //. Le principe est d'utiliser le PC pour piloter (modifier la période, créer un scénario...) un dispositif externe 'base de temps' dont c'est le travail (un PIC, une liaison série et un peu de code dans le PIC peuvent suffire).

Ta solution 'kernel' pourrait avoir de graves conséquences sur la stabilité du système ou des autres applications si la section critique est longue...