doxzrb8721 2015-12-01 01:33
浏览 77
已采纳

Golang如何确保数据在另一个Goroutine访问时在Goroutine中完成

Hi guys I am trying to make a party system using websockets where people can enter a queue and then get matched with 5 people similar to them. Right now I'm having trouble with this part:

type PartyHub struct {
    Partys             map[string]*Party
    PartialPartys      []*PartialParty
    Queue              []*Member
    AddParty           chan *Party
    RemoveParty        chan *Party
    AddPartialParty    chan *PartialParty
    RemovePartialParty chan *PartialParty
    EnterQueue         chan *Member
    LeaveQueue         chan *Member
    Mu                 sync.Mutex
}
// Run will begin monitoring the channels
// to register and unregister partys as they are
// created or destroyed
func (p *PartyHub) Run() {
    for {
        select {
        case member := <-p.EnterQueue:
            go p.SortMemberIntoParty(member)
            go p.SortMemberIntoParty(member)
            go p.SortMemberIntoParty(member)
            go p.SortMemberIntoParty(member)
            go p.SortMemberIntoParty(member)

            log.Println(p.PartialPartys)
        case party := <-p.AddPartialParty:
            p.Mu.Lock()
            defer p.Mu.Unlock()
            p.PartialPartys = append(p.PartialPartys, party)
        }
    }
}

// SortMemberIntoParty will take a new user entering the queue and find an appropriate Party
// for the member to join, taking into account RankTollerance, Rank
func (p *PartyHub) SortMemberIntoParty(member *Member) {
    p.Mu.Lock()
    defer p.Mu.Unlock()
    if len(p.PartialPartys) == 0 {
        log.Println("Here")
        newParty := &PartialParty{Accepting: true, Members: []*Member{member}}
        p.AddPartialParty <- newParty
        return
    }

    foundPartyForMember := false
    for _, party := range p.PartialPartys {
        goodFitForParty := true
        for _, partyMember := range party.Members {
            log.Println(member.Type == partyMember.Type, member.Rank >= partyMember.Rank-partyMember.RankTol, member.Rank <= partyMember.Rank+partyMember.RankTol)
            if member.Type == partyMember.Type && member.Rank >= partyMember.Rank-partyMember.RankTol && member.Rank <= partyMember.Rank+partyMember.RankTol {

                goodFitForParty = true
                continue
            } else {
                goodFitForParty = false
                break
            }
        }

        if !goodFitForParty {
            continue
        } else {
            foundPartyForMember = true
            party.Mu.Lock()
            defer party.Mu.Unlock()
            party.Members = append(party.Members, member)
            if len(party.Members) == 5 {
                party.Accepting = false
                go party.SendReadyCheck()
            }
            break
        }
    }


    if !foundPartyForMember {
        newParty := &PartialParty{Accepting: true, Members: []*Member{member}}
        p.AddPartialParty <- newParty
    }

    log.Println("Sorting Members")
}

The only problem is, the 5 goroutines seem to finish quicker than the data knows what happened.

For example: p.PartialPartys says it has no parties.

What I need is to have p.PartialPartys always up to date for every goroutine that accesses that field of the PartyHub struct I though the sync.Mutex would do this for me but it doesn't seem to be the case, can anybody tell me the best way to keep all my goroutines in sync with the same data?

  • 写回答

1条回答 默认 最新

  • doujiao1984 2015-12-01 03:46
    关注

    So with this implementation, none of your five goroutines are going to be be able to run in parallel because they are all trying to acquite the p.Mu mutex. And looking at the way you're using the p.AddPartialParty channel, I wouldn't be surprised if the code can deadlock.

    Consider the following sequence of events:

    1. One of the SortMemberIntoParty goroutines starts running and acquires the mutex.
    2. It sends a value on p.AddPartialParty, which is received by Run. Run then tries to acquire the mutex, so blocks.
    3. The original SortMemberIntoParty goroutine completes and releases the mutex.
    4. A different SortMemberIntoParty goroutine acquires the mutex, and tries to send another value to p.AddPartialParty.
    5. The goroutine blocks because there is no one ready to read the value (Run is still waiting on the mutex before it gets back to the select statement).

    So now you've got a blocked goroutine holding a lock needed by the receiving end of the channel. Also note that at (4) you won't see the new PartialParty because Run hasn't managed to add it yet.

    If you do need the mutex, then it might be easier to just have your SortMemberIntoParty goroutine update p.PartialPartys directly rather than using the channel: you already know that no one else will be accessing the variable concurrently.

    It's also worth remembering that this mutex essentially means that all SortMemberIntoParty goroutines will be serialised. If you were using goroutines in the hope of achieving parallelism here, the mutex defeats that.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 有了解d3和topogram.js库的吗?有偿请教
  • ¥100 任意维数的K均值聚类
  • ¥15 stamps做sbas-insar,时序沉降图怎么画
  • ¥15 unity第一人称射击小游戏,有demo,在原脚本的基础上进行修改以达到要求
  • ¥15 买了个传感器,根据商家发的代码和步骤使用但是代码报错了不会改,有没有人可以看看
  • ¥15 关于#Java#的问题,如何解决?
  • ¥15 加热介质是液体,换热器壳侧导热系数和总的导热系数怎么算
  • ¥100 嵌入式系统基于PIC16F882和热敏电阻的数字温度计
  • ¥15 cmd cl 0x000007b
  • ¥20 BAPI_PR_CHANGE how to add account assignment information for service line