Boost logo

Boost Users :

Subject: Re: [Boost-users] Strange boost::threads behaviour
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-02-19 20:52:41

On 19/02/2015 21:11, Lorenzo Trivelli wrote:
>> Typically the way things work is that as long as a lock (or
>> whatever it is you're using -- you didn't actually say) goes
>> uncontended, or minimally contended such that a spin resolves it,
>> then it will allocate no kernel handles. A kernel handle is only
>> required when the lock is contended for sufficiently long that it
>> needs to put the thread to sleep.
> thank you ver much for your response,
> I'll try to detail the issue better.
> The original software is an conccurrent transactional server which
> preallocates a certain number of ftherads (say 100 ~ 130) and then
> accepts and serves TCP/IP connections in a request-reply fashion.

While thread-per-connection is a popular model for older or small-scale
software (because it's easy to program), performance suffers quite
significantly when a large number of connections are in use, especially
when each connection needs to contend on the same locks.

Especially if the workload is mostly I/O bound rather than CPU bound,
you may want to consider a "properly" async design (eg. using
Boost.Asio) where #threads == #cores (or thereabouts) and connection
processing can shift between threads as needed.

> Obviuosly, it heavily uses boost::shared_ptr to handle these connections,
> but in the end I managed to use other shared pointers (for testing purposes only)
> and the boost::thread object alone and a single shared static mutex object
> so, the sample program starrts, creates some threads which simply does some memory
> allocations loops and s. In the main function I enclosed all the code between brackets,
> and I print the handle count before and after, ans it's not the same,
> something like
> int main() {
> GetProcessHandleCount()....
> {
> [creates threads and waits for their termination through ->join]
> }
> GetProcessHandleCount()....
> }
> The difference between the first and the last count is not always the same, it
> depends on how much concccurent threads you create and how much iterations of the
> same loop each thread does.

Well, as I said that is not an error if some synchronization objects
(eg. mutexes) still exist.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at