Boost logo

Boost Users :

From: Kirit Sælensminde (kirit.saelensminde_at_[hidden])
Date: 2007-10-03 23:21:34


Steven Woody wrote:
> On 10/2/07, Kirit Sælensminde <kirit.saelensminde_at_[hidden]> wrote:
>> Steven Woody wrote:
>>> hi,
>>>
>>> i am doing a job and considering if boost.thread can help.
>>>
>>> ...
>>>
>>> in breif, you can think my code in a way of producer/consumer pattern.
>>> the producer is a rouine which will be called by many threads ( which
>>> are actaully connected sockets created by a listening socket ), and
>>> the consumer routine will be called by another thread ( which is
>>> actually GUI's main thread ). what i expected is:
>>>
>>> 1, only one producer can write to the shared data;
>>> 2, when a producer is writting, other producers have to busy waiting;
>>> and the GUI thread should immediately exit;
>>> 3, when GUI thread is reading, no producer can write to the shared data;
>> From the sound of what you're trying to do then yes. This page shows
>> how to make a queue and add and remove items from it.
>> http://www.boostcookbook.com/Recipe:/1234841
>>
>>
>> K
>>
>
> god! i found the boost's documentation is very hard to read, it is not
> for a beginner! and, it seems if i want to use the mutex and lock, the
> threads themself have to be created using boost, is it true? it's
> impossible to me since the threads had been created by other member of
> our team and i am just writing library codes for them.

The thread can be created in any way and the mutexes, locks and
conditions will work.

The Boost documentation is fine so long as you already understand
threading issues. Shared state threading is very, very hard and
something you should expect to get wrong more often than not even after
a lot of practice.

The trick is to share as little as possible. If you can get away with
sharing nothing between threads then it is actually very simple to do.

K


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net