Maison > développement back-end > Golang > le corps du texte

Le programme Go fonctionne avec un seul canal et se retrouve dans une impasse lorsqu'un nouveau canal est introduit

王林
Libérer: 2024-02-09 23:20:10
avant
1108 Les gens l'ont consulté

Go 程序使用单通道工作,并在引入新通道时陷入死锁

Dans le langage Go, les opérations simultanées du programme sont implémentées via des canaux. Un canal est un type spécial utilisé pour transférer des données. Il permet l'échange de données et la communication entre les goroutines. Cependant, si vous travaillez avec un seul canal dans votre programme et que vous ne le gérez pas correctement lors de l'introduction d'un nouveau canal, un blocage peut se produire. Dans cet article, l'éditeur PHP Xiaoxin expliquera en détail les problèmes de travail monocanal et de blocage dans les programmes Go, et comment éviter les blocages.

Contenu de la question

Je suis nouveau dans les canaux Go et j'essaie d'apprendre les canaux Go en créant un noyau fictif et en gérant les interactions via les canaux. Le but de cet exemple de programme est que plusieurs processus (2) envoient simultanément des demandes d'allocation de mémoire au noyau en utilisant un seul canal, et d'autres processus pour envoyer des demandes de libération de mémoire au noyau en utilisant des canaux uniques mais différents .

+-------------+
                           +------------------+       |             |
                          -> Alloc. Mem. Ch.  |<--\   |             |
+-----------------+   ---/ +------------------+   >-->|   Kernel    |
|   Process A     |<--     +------------------+ -/    |             |
+-----------------+   \--> |  Realse Mem. Ch. |<      |             |
                           +------------------+       +-------------+
Copier après la connexion

Si je n'ai que des demandes d'allocation, le programme fonctionne, une fois que j'introduis des demandes de release, le programme se retrouve dans une impasse.

Notez que le processus crée également une file d'attente de réponses lors de l'envoi d'une demande d'allocation. Cependant, cela n'est pas affiché dans l'image ci-dessus car cela ne fait pas partie du problème.

La procédure complète est la suivante :

package main

import (
        "fmt"
        // "log"
        "time"
)

const (
        _ float64 = iota
        LowPrio
        MedPrio
        HghPrio
)

// Kernel type to communicate between processes and memory resources
type Kernel struct {
        reqMemCh chan chan int
        rlsMemCh chan int
}

func (k *Kernel) Init() {
        k.reqMemCh = make(chan chan int, 2)
        k.rlsMemCh = make(chan int, 2)
        go k.AllocMem()
        go k.RlsMem()
}

// Fetch memory on process request
func (k *Kernel) GetReqMemCh() chan chan int {
        return k.reqMemCh
}

func (k *Kernel) GetRlsMemCh() chan int {
        return k.rlsMemCh
}

func (k *Kernel) AllocMem() {
        // loop over the items (process reply channels) received over
        // the request channel
        for pCh := range k.GetReqMemCh() {
                // for now think 0 is the available index
                // send this as a reply to the exclusive process reply channel
                pCh <- 0
                close(pCh)
        }
}

// Release memory
func (k *Kernel) RlsMem() {
        // we do not have to anything here
}

// Process type which requests memory
type Proc struct {
        ind     int
        prio    float64
        exeT    time.Time
        count   int
        memInd  int
        rqMemCh chan chan int
        rlMemCh chan int
}

func (p *Proc) Init(
        ind int,
        prio float64,
        rqMemCh chan chan int,
        rlMemCh chan int,
) {
        p.ind = ind
        p.prio = prio
        p.memInd = -1
        p.rqMemCh = rqMemCh
        p.rlMemCh = rlMemCh
}

func (p *Proc) GetReqMemCh() chan chan int {
        return p.rqMemCh
}

func (p *Proc) GetRlsMemCh() chan int {
        return p.rlMemCh
}

func (p *Proc) ReqMem() {
        // create the reply channel exclusive to the process
        // this channel will return the allocated memeory id/address
        rpCh := make(chan int)
        // send the reply channel through the request channel
        // to get back the allocation memory id
        p.GetReqMemCh() <- rpCh
        // Below line is blocking ...
        for mi := range rpCh {
                p.memInd = mi
        }
}

func (p Proc) RlsMem() {
        p.GetRlsMemCh() <- 0
}

func (p Proc) String() string {
        return fmt.Sprintf(
                "Proc(%d): Memory(%d), Count(%d)",
                p.ind+1, p.memInd+1, p.count,
        )
}

func main() {

        k := &Kernel{}
        k.Init()

        p := &Proc{}
        for i := 0; i < 3; i++ {
                p.Init(i, LowPrio, k.GetReqMemCh(), k.GetRlsMemCh())
                p.ReqMem()
                p.RlsMem()
        }

        time.Sleep(time.Second)
}
Copier après la connexion

Les exceptions sont les suivantes :

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.Proc.RlsMem(...)
        main.go:100
main.main()
        main.go:119 +0xc5

goroutine 6 [chan receive]:
main.(*Kernel).AllocMem(0x0?)
        main.go:41 +0x5e
created by main.(*Kernel).Init in goroutine 1
        main.go:25 +0xc5
exit status 2
Copier après la connexion

Toute aide serait grandement appréciée.

Bravo,

DD.

Solution de contournement

En tant que commentateur britannique, vous disposez d'un canal tampon qui a atteint sa capacité mais n'a rien à lire.

Selon le tour de langue (1 2), envoyez et recevez des blocs jusqu'à ce que l'autre partie soit prête. Bien que les canaux tamponnés offrent ici une certaine tolérance, une fois le tampon plein, le comportement est le même.

Ce problème peut être résolu en ajoutant un utilisateur de k.rlsMemCh. Si vous n'avez rien de prévu pour cela, supprimez le canal ou utilisez la logique pour le vider temporairement.

<code>func (k *Kernel) Init() {
        k.reqMemCh = make(chan chan int, 2)
        k.rlsMemCh = make(chan int, 2)
        go k.AllocMem()
        go k.RlsMem()
}

func (k *Kernel) AllocMem() {
        for pCh := range k.GetReqMemCh() {
                pCh <- 0
                close(pCh)
        }
}

func (k *Kernel) RlsMem() {
        // TODO: Add a for-select or for-range over k.rlsMemCh here
}

</code>
Copier après la connexion

Le drainage peut ressembler à ceci :

func (k *Kernel) RlsMem() {
        for {
                <-k.GetRlsMemCh()
        }
}
Copier après la connexion

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
source:stackoverflow.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal
À propos de nous Clause de non-responsabilité Sitemap
Site Web PHP chinois:Formation PHP en ligne sur le bien-être public,Aidez les apprenants PHP à grandir rapidement!