Re: [Boost-users] Strange boost::threads behaviour

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.