Boost Thread

Discussion about everything. New games, 3d math, development tips...
Post Reply
Bate
Posts: 364
Joined: Sun Nov 01, 2009 11:39 pm
Location: Germany

Boost Thread

Post by Bate »

I have a question on boost thread and it might sound stupid (sorry for that) but from the docs I just can't figure it out. What gets actually locked by using a mutex?

example:

Code: Select all

// Copyright (C) 2001-2003
// William E. Kempf
//
//  Distributed under the Boost Software License, Version 1.0. (See accompanying 
//  file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)

#include <boost/thread/mutex.hpp>
#include <boost/thread/thread.hpp>
#include <iostream>

boost::mutex io_mutex; // The iostreams are not guaranteed to be thread-safe!

class counter
{
public:
    counter() : count(0) { }

    int increment() {
        boost::mutex::scoped_lock scoped_lock(mutex);
        return ++count;
    }

private:
    boost::mutex mutex;
    int count;
};

counter c;

void change_count()
{
    int i = c.increment();
    boost::mutex::scoped_lock scoped_lock(io_mutex);
    std::cout << "count == " << i << std::endl;
}

int main(int, char*[])
{
    const int num_threads = 4;
    boost::thread_group thrds;
    for (int i=0; i < num_threads; ++i)
        thrds.create_thread(&change_count);

    thrds.join_all();

    return 0;
}
There is a global "io_mutex" and a class member "mutex". So which locks what for how long when the corresponding functions are called?

Also, since I'm planning to use a 2nd thread for network code I am not quite sure where and how to lock/share data between the network thread and irrlicht's main thread.

Let's say the network class in thread 2 receives a new position for an existing unit. This unit, represented by a typical irrlicht related class, has a position member. So, how do I get the received position into the unit class without any problems? Or is there already a general problem because Irrlicht itself is not what's called "thread-safe"?
Never take advice from someone who likes to give advice, so take my advice and don't take it.
Brainsaw
Posts: 1183
Joined: Wed Jan 07, 2004 12:57 pm
Location: Bavaria

Post by Brainsaw »

IIRC Irrlicht is not thread safe, but that's not a problem for your situation. I would add a message pipeline that gets locked and filled by the network thread and later locked and filled by the Irrlicht thread. I am not very experienced when it comes to multithread programming (due to the trouble we have with this here at work makes me sure Satan invented it ;) ), but I found a tutorial on the net (I think it was at gamedev.net ... can't find it right now) where they lock the single messages that get added to the pipeline. My way would be:

(Network thread)

receive a packet
create an internal message from the packet
lock the pipeline
insert the message
unlock the pipeline

(Irrlicht thread)

lock the pipeline
check for messages
remove messages from the pipeline (if new messages were added)
unlock the pipeline
process the messages from the pipeline

The time between the lock and unlock should be kept as short as possible, so I think it's best to just add and remove the messages while the pipeline is locked.

This way works with two threads (at least it should), I think it gets more complicated if you have more than one thread reading from the pipeline (lock the messages, when to remove them?), that's why I didn't yet start to add multithreading to my IrrOde project, but I'm planning to do that (I have at least 3 threads, one for physics, one for Irrlicht and one for network).
Dustbin::Games on the web: https://www.dustbin-online.de/

Dustbin::Games on facebook: https://www.facebook.com/dustbingames/
Dustbin::Games on twitter: https://twitter.com/dustbingames
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

A mutex simply locks itself, so to say. Or better, it protects its dedicated critical section, as long as everyone uses the mutex. There is no safety guaranteed by a mutex, because everyone needs to adhere to the mutex protocol (which can be enforced, e.g., by a set of protecting methods). The only additional help of a mutex is, that changing and testing it is implemented by atomic commands (and is hence thread-safe) and that there are additional methods which let processes sleep until the mutex is free again etc.
Bate
Posts: 364
Joined: Sun Nov 01, 2009 11:39 pm
Location: Germany

Post by Bate »

Alright, thanks guys.

Brainsaw: A message system sounds reasonable to me, I'm gonna try something similar. Also, good luck in your own thread hell. :)

hybrid wrote:There is no safety guaranteed by a mutex, because everyone needs to adhere to the mutex protocol [...]
Hm, not sure what that means. I thought the very point in using mutexes is to guarantee safety. So if I lock/trylock/timedlock each resource that is shared before accessing it and unlock it afterwards, it's still not good enough?
Never take advice from someone who likes to give advice, so take my advice and don't take it.
Keyosz
Posts: 4
Joined: Wed Jul 14, 2010 8:31 am
Location: Italy

Post by Keyosz »

Bate wrote:...So if I lock/trylock/timedlock each resource that is shared before accessing it and unlock it afterwards, it's still not good enough?
Yes it is safe, but end up slow, because it serialize the parallel path execution if the shared resources are heavily accessed/used by both threads, because when each thread reach the execution point where they need to access the shared resource they are like put on a "wait queue" and stopped untill the other side have done, so this way you could end up wasting the powerfull of multi-thread programming.

I am not very skilled in multi-threading programming, but from the little experience i had i have got that it is a best pratice to use a separate thread only for big tasks, like a thread for network, one for audio and one for the gfx, subdividing the main app into big tasks and setting up a dedicated thread for every one take advantage of the nowdays multicore cpu power, but that way the communication is reduced to few main messages.

I say that because using a thread for every little thing in an application end up wasting more time to syncronize (eg. mutex/critical sections) shared resource access and sending data from a thread to another than really do the work directly in the source thread ;)
Nalin
Posts: 194
Joined: Thu Mar 30, 2006 12:34 am
Location: Lacey, WA, USA
Contact:

Post by Nalin »

If you want to get started with multithreaded programming, give this free book a read:
http://www.greenteapress.com/semaphores/

It can help teach the basics.
Bate
Posts: 364
Joined: Sun Nov 01, 2009 11:39 pm
Location: Germany

Post by Bate »

Nice, thanks a lot :D

The taped lecture is also very good.
Never take advice from someone who likes to give advice, so take my advice and don't take it.
Post Reply