Boost logo

Boost Users :

From: Vsevolod Vlaskin (vlaskine_at_[hidden])
Date: 2006-08-07 21:19:06


Hi,

Would not it be more interesting then to write a
task-distributing class with the underlying mechanism
as a policy (thread pool, process pool, even
single-threaded)?

Best regards,

Vsevolod

--- Ovanes Markarian <om_boost_at_[hidden]> wrote:

> Tony
>
> thanks for your answer. May be you better described
> the point. When I wrote the idea, I was
> uncertain, how to name the structure, because it
> does not implement a real pool pattern. But the
> idea is to specify how many threads are allowed to
> be executed simultaneously and execute tasks on
> them. Tasks can be taken from a queue, "priority
> queue" or any other user specific queue. But
> these are implementation details.
>
>
>
> With Kind Regards,
>
> Ovanes Markarian
>
>
> On Mon, August 7, 2006 16:33, Gottlob Frege wrote:
> > On 8/7/06, Ovanes Markarian
> <om_boost_at_[hidden]> wrote:
> >>
> >>
> >> Even if it is true, it should be possible to
> restict the creation to some
> >> certain number of
> >> threads (even without reuse) and wait until at
> least one of these will
> >> finish the execution,
> >> before new ones are created/started.
> >>
> >> What if I program a server which should
> accomplish tasks, but with a
> >> maximum ammount of 1024
> >> threads. Then a function get_thread should block,
> until one of executing
> >> threads becomes ready or
> >> terminates. Or do you think such a system should
> create unlimited number
> >> of threads?
> >>
> >> I will read tonight a little bit more how the
> threads in Solaris, Windows
> >> and other Unix Systems
> >> work (especiall in regards of creation). On the
> other hand on Solaris and
> >> where threads are cheap
> >> to create a new thread should be created by the
> pool anyway...
> >
> >
> >
> > Unless it has changed recently, thread Creation on
> Windows is expensive.
> >
> > However, instead of a thread-pooling system, I'd
> prefer a Task-queue system
> > - create a task, add it to a queue, and the queue
> executes it on the next
> > available thread - completely eliminate the
> concept of a thread.
> >
> > Tony
> >
> >
> > With Kind Regards,
> >>
> >> Ovanes Markarian
> >>
> >>
> >>
> >> On Mon, August 7, 2006 14:52, John Reid wrote:
> >> >
> >> >
> >> > Ovanes Markarian wrote:
> >> >> What I miss now in the threading library is
> the ability to reuse the
> >> thread. I think thread
> >> >> creation in the OS is an expensive task. If
> one has created thread,
> >> there should be a possiblity
> >> >> to reuse it. I understand it is possible to
> pass a function to the
> >> thread which executes tasks
> >> >> from the queue and therefore reuses threads,
> but this involves user
> >> implementation of such a
> >> >> function each time this programming pattern
> needs to be fullfilled.
> >> >
> >> > If I remember correctly thread creation in
> Solaris at least is cheap and
> >> > Sun's developer manuals explicitly recommend
> creating threads as needed
> >> > rather than pooling them.
> >> >
> >> > I'm not sure about other OSes. It might be
> worth checking before
> >> > designing such a pool.
> >> >
> >> > John.
> >> >
> >> > _______________________________________________
> >> > Boost-users mailing list
> >> > Boost-users_at_[hidden]
> >> >
>
http://lists.boost.org/mailman/listinfo.cgi/boost-users
> >> >
> >>
> >> _______________________________________________
> >> Boost-users mailing list
> >> Boost-users_at_[hidden]
> >>
>
http://lists.boost.org/mailman/listinfo.cgi/boost-users
> >>
> > _______________________________________________
> > Boost-users mailing list
> > Boost-users_at_[hidden]
> >
>
http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
>
http://lists.boost.org/mailman/listinfo.cgi/boost-users
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


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