Concurrency and locking in a chat server
This is a nice project to learn concurrency on, and you've already identified a few issues that concern you, and you're right in some ways. Go documentation recommends using channels when possible, over mutexes. The documentation in the sync package says: "Other than the Once and WaitGroup types, most are intended for use by low-level library routines. Higher-level synchronization is better done via channels and communication."

Channels are your friend in Go, and you should use them liberally (well, more liberally than mutexes).

There are some special cases with channels, though, and your code has a good example of how they can be used in a broken way. Your concurrency is not nearly as significant as you think it is. I will focus on this code for the moment, and we'll simplify it down, and then get back to the concurrency problem in a bit...

Client handler

This code....


func (r *Server) handleConn(conn net.Conn) {
    reader := bufio.NewReader(conn)
    name, e := reader.ReadString('\n')
    name = strings.TrimSpace(name)
    if e != nil {
        conn.Close()
        return
    }

    c := &amp;client{conn, reader, name}
    r.addClient(c)
    r.publishMessage(c.name + " has joined the server\n")
    r.handleClient(c)
}

func (r *Server) handleClient(c *client) {
    for {
        msg, e := c.reader.ReadString('\n')
        if e == io.EOF {
            c.conn.Close()
            r.deleteClient(c)
            r.publishMessage(c.name + " has left the server\n")
            return
        } else if e != nil {
            continue
        }
        r.messageChan &lt;- message{c.name + ": " + msg, c}
    }
}



... takes a client network connection, pulls the name, and then establishes a loop for reading and distributing messages. It distributes the messages by pushing them on to the r.messageChan channel. Let's simplify that code a whole bunch, and point out some problems as we go.

First up, you need to learn the defer statement, and use it for closing the client connection. If you change the first line of the function to be:

func (r *Server) handleConn(conn net.Conn) {
    defer conn.Close()


now you don't need to worry about closing it in a number of other places. Just returning from the function is enough to close it.

Secondly, you should use a scanner... not a Reader. See: Scanner which has the documentation "Scanner provides a convenient interface for reading data such as a file of newline-delimited lines of text." Scanner defaults to using line-termination (which is what you have) so it's easy to set up. Your code:


    reader := bufio.NewReader(conn)



becomes:

     scanner := bufio.NewScanner(conn)


Note that Scanner never returns an EOF error, it just returns a false scan at EOF (or any other error). The advantage for you of a scanner is that it simplifies your loops, and error handling. This is not obvious immediately in your case as you scan the name, but will become apparent when processing messages. To get the name, you need:

// find the next end-of-line.. (or perhaps EOF)
if !scanner.Scan() {
    // could not scan anything on the first scan... odd... no name.
    // the scanner.Err() may have a value if there's a problem, but we don't care.
    return
}
name := strings.TrimSpace(scanner.Text())


OK, that's how you get the name.... and now we can create the client (using the scanner instead of reader) and we also use a defer function to remove the client instead of shifting that logic in to some other place (keeping the clean-up code in the same place as the mess-up code is important for maintainability). Also, we should relocate the "publish" methods in to the addClient and deleteClient methods (where they really should be anyway):

c := &amp;client{conn, scanner, name}
r.addClient(c)
defer r.deleteClient(c)
r.handleClient(c)


OK, so now we have a client that can process incoming messages, let's look at that code, but using a scanner now instead of a reader, and it does not need to do the deleteClient or the related "publish" of the deletion. It also does not need to close the connection:

func (r *Server) handleClient(c *client) {
    for c.scanner.Scan() {
        msg := c.scanner.Text()
        r.messageChan &lt;- message{c.name + ": " + msg, c}
    }
    // we could check scanner.Err() here, but we are ignoring all non-EOF errors anyway
}


Now, that looks neat... so small now that it's hardly worth having it's own function, let's pull it back in to the handleConn function (which we will rename to handleClient because I prefer client... and we'll remove the scanner from the client struct because no-one else uses it in any other place... our handleClient method is now:

func (r *Server) handleClient(conn net.Conn) {
    defer conn.Close()

    scanner := bufio.NewScanner(conn)

    // read off the first line as the "name"

    // find the next end-of-line.. (or perhaps EOF)
    if !scanner.Scan() {
        // could not scan anything on the first scan... odd... no name.
        // the scanner.Err() may have a value if there's a problem, but we don't care.
        return
    }
    name := strings.TrimSpace(scanner.Text())

    // register our client in to the control systems.
    c := &amp;client{conn, name}
    r.addClient(c)
    defer r.deleteClient(c)

    // send messages in to the channel.
    for scanner.Scan() {
        r.messageChan &lt;- message{name + ": " + scanner.Text(), c}
    }
}


Now, that's a bunch simpler, especially the reduced error handling, and the reduced content in the client.    

There were a few things to hammer out here. We shifted the printing of messages like X has joined the server and X has left the server in to the addClient and deleteClient methods respectively. This reduces the mixed logic of handling a client and also reporting activity in this function, and shifts it to the more logical place where we are actually adding and deleting things. We used defer functions to handle cleanup of resources at the same time/place that the resources were created. We used a scanner instead of a reader.

messageChan

Let's cover that concurrency issue I mentioned earlier. It comes down to the messageChan. The problem is only one client is busy at a time. Let me explain... this code here:


r.messageChan &lt;- message{name + ": " + scanner.Text(), c}



pushes messages on to the channel, and this code pulls them off:


for {
    m := &lt;-r.messageChan
    .... distribute the messages to other clients
}



You would think that multiple clients could all be pushing messages, and the for-loop is pulling them and distributing them at the same time. Unfortunately, all the clients "block" at the point where they push the message, and they all wait there, until the for-loop starts, and it will pull just one message. That one message will be processed, and the client that happened to have its message pulled, will then go off and wait for another message - all the other clients are still blocked. Once the for loop has sent the message off, it will come back and read another from the channel, and one other client will be lucky enough to have its message delivered.

This is because you have created an unbuffered channel. The documentation has this to say: "If the capacity is zero or absent, the channel is unbuffered and communication succeeds only when both a sender and receiver are ready." Since the receiver is only ready once each loop, the receiver essentially serializes all the clients.

You need to declare your channel with some buffer size if you want to avoid this issue. Even a size of 1 would be beneficial. A larger buffer may result in caching of messages but that should not be a problem.

Communication instead of Mutexes

Communication in Go is an odd concept to explain. The purpose of mutexes is to allow safe access to resources from multiple go-routines. Communication is sort of the opposite - communication basically implies only one go-routine ever accesses a resource, so mutexes are not needed, but we can communicate the changes (normally via a channel) to that go-routine.

If only one routine accesses a resource, no mutex is needed. Let's see how we can apply that to your code. Your "server" code really has three things going on...


clients get added
messages get distributed
clients get removed.


You've already got a channel for the messages, so let's look at the other parts....


func (r *Server) addClient(c *client) {
    r.m.Lock()
    r.clients[c] = struct{}{}
    r.m.Unlock()
}

func (r *Server) deleteClient(c *client) {
    r.m.Lock()
    delete(r.clients, c)
    r.m.Unlock()
}



Let's turn those in to channels instead:

func (r *Server) addClient(c *client) {
    r.added &lt;- c
}

func (r *Server) deleteClient(c *client) {
    r.deleted &lt;- c
}


We will have to create those channels (with some buffering) on the Server... but, that's how we communicate the add/remove from the client.

How do we handle that on the server? Currently the server code looks like:


func (r *Server) sendMessages() {
    for {
        m := &lt;-r.messageChan
        r.m.RLock()
        for k := range r.clients {
            if k != m.client {
                go k.conn.Write([]byte(m.message))
            }
        }
        r.m.RUnlock()
        fmt.Print(m.message)
    }
}



If we listen for communication from all channels, not just the messageChan, we can do it all in that routine (and no need for mutexes because we're the only ones to manipulate the client map.

func (r *Server) sendMessages() {
    for {
        select {
        case m := &lt;-r.messageChan:
            for k := range r.clients {
                if k != m.client {
                    go k.conn.Write([]byte(m.message))
                }
            }
            fmt.Print(m.message)
        case c := &lt;-r.added:
            r.publishMessage(c.name + " has joined the server\n")
            r.clients[c] = struct{}{}
        case c := &lt;-r.deleted:
            r.publishMessage(c.name + " has left the server\n")
            delete(r.clients, c)
        }
    }
}


Now we can even remove the client map from the Server completely, and keep it local inside thesendMessages` go-routine.

Read up on the select statement which is how communication from multiple sources is handled: https://golang.org/ref/spec#Select_statements

Conclusion

This post has been long enough already... hopefully you'll get something out of it. I hope that you at least get how the unbuffered channels can impact things, and that communication with select-statements allows you to localize resources to just one routine, meaning mutexes are not needed.