Hi,
as I said, it depends: do you see any advantage for your application
when you use threads, i. e. the ability to fulfill tasks in parallel
with in one job?
It seems to me that the server has no need for threads, but the client ;-)
From what you describe, it is really not easy to understand what the
benefit of threads could be for your application, but may be think of
the case, that the server does not finish the request of client #1, so
that client #2 is waiting for ever and ever ... The typical case: the
client #1 requests from the server 1000 events, but gets only 999. No
way out, client #2 blocks and #1 as well.
Think about your application in terms of what is the benefit of having
parallel flows of control, may be that helps for your decision.
I would recommend to you reading (or taking a look at) the following
book, which I found REALLY useful. I used several of these patterns in
my projects bothe in industry or privately and they can be adapted quite
well tou your needs:
Douglas Schmidt et al.
Pattern-Oriented Software Architecture: Patterns for Concurrent and
Networked Objects
The book can be used to tackle specific software development problems or
read from cover to cover to provide a fundamental understanding of the
best practices for constructing concurrent and networked applications
and middleware.
Or take a quick look at http://www.cs.wustl.edu/~schmidt/POSA/
BTW Douglas Schmidt created the ACE-Framework.
May be that helps. If you need some further private discussions on your
problems, we can continue privately, not disturbing the roottalk.
Greetings,
Marc
cstrato@EUnet.at wrote:
> Dear Marc
>
> Thank you for your reply. Your answer causes some more questions:
>
> Do you think it is better to use processes than threads?
>
> What I would like to do is the following:
> Assume two clients connected to a server and asking the server to do
> something.
> However, one client has to wait until the server has processed the
> request
> of the second client. Then the second client can resume.
> What is the best way to this?
>
> As far as I understand from some reading, the parent process can fork()
> a child process and can wait() for the child process to complete?
> But is it also possible that one child process can wait for another
> child process? Or do I misunderstand something?
>
> Regarding Go4, I tried to study the code, but it is wrapped into so
> many Go4 classes, so it is hard to understand, especially since it is
> not possible yet to download the source code.
>
> Do you mean that the server should start a separate TServerSocket for
> every client which connects to it?
>
> Thank you in advance
>
> Best regards
> Christian
>
> Marc Hemberger wrote:
>
>> Hi Christian,
>>
>> cstrato@EUnet.at wrote:
>>
>>>Dear Rooters
>>>
>>>Maybe this is a good opportunity to ask some questions about TThread:
>>>
>>>1, In which cases would it be recommended to use class TThread?
>>>
>> If you can not think of some use for threads in your application,
>> then you don't need them ;-) But I think, if you want to see some of
>> the uses of threads in general, take a look at Valeris 'Literature
>> List' in one of his previous mails:
>>
>>
>>TrollTech Web site http://doc.trolltech.com/2.3/threads.html says:
>>
>>" . . . This document is intended for an audience that has knowledge
>>
>>and experience with multithreaded applications. Recommended reading:
>>
>> a.. Threads Primer: A Guide to Multithreaded Programming
>> b.. Thread Time: The Multithreaded Programming Guide
>> c.. Pthreads Programming: A POSIX Standard for Better Multiprocessing (O'Reilly Nutshell)
>> d.. Win32 Multithreaded Programming
>>
>>Take also a look at http://go4.gsi.de.
>>
>>>2, Support for Dual-Processor machines:
>>>Sorrowly, I do not have such a machine :-(, but for interest:
>>>If you write programs in root and want your program to take advantage
>>>of a dual-processor machine:
>>>What is the best way to achieve this goal?
>>>Do you need to use PROOF?
>>>Would TThread support dual-processors?
>>>As far as I understand, Mach (MacOSX) threads support SMP. Does
>>>root TThread support this? What about Linux? Does not WinNT also
>>>support threads?
>>>
>> Dual processor machines are a bit a different topic. The simplest way
>> of exploiting two CPUs is the use of two processes, which each use
>> one processor. They act independently, so they are really independent.
>>
>> When you want to use only one process, then you might want to use
>> threads within a single process. But then, sharing resources in one
>> process so that they can be used within different threads can and
>> will cause an overhead, which reduces the performance of your program
>> may be a lot.
>>
>> Most of the SMP implementations are worked out quite well (even for
>> Linux;-), so the OS can deal with it in general. Cache coherency is
>> causing troubles, but works well.
>>
>> Don't expect too much of a multiprocessor machine when you use
>> threads. What you will get is at first trouble, then more trouble and
>> in the end perhabs a gain of 50% in performance, but never the
>> expected 100% (as you would have with two didtinct processes). At
>> least what my experience tells me (from Linux, HP, Sun and AIX
>> multi-processor machines).
>>
>>>3, The tutorial spyserver.C shows how a TServerSocket can handle
>>>requests from two or more clients. No threads are necessary.
>>>In which cases would threads be necessary?
>>>Could this tutorial be expanded to show how to use TThreads?
>>>
>> Hmm, the server uses one socket, different clients attach to this
>> port and "spy" for histograms. Imagine the case, that you want to use
>> different sockets ... Check for the Go4 page, which does something
>> like that: a per-client connection in a thread, which will never/not
>> block, when nothing comes.
>>
>>>Thank you.
>>>
>>>Best regards
>>>Christian
>>>
>> Greetings,
>>
>> Marc
>>
>>
>>>----------------------------------
>>>C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
>>>V.i.e.n.n.a, A.u.s.t.r.i.a
>>>
>>>--
>>>Dr. Marc Hemberger
>>> /\_/\
>>> ( o.o )
>>> > ^ <
>>> |\ _,,,---,, EMBL
>>> ZZZzz /,`.-'`' -. ;-;;,_ C&N Group
>>> |,4- ) )-,_. ,\ ( `'-' Meyerhofstr. 1
>>> '---''(_/--' `-'\_) 69117 Heidelberg
>>> Germany privat:
>>> Marc.Hemberger@embl-heidelberg.de MHemberger@csi.com
>>>
>>> ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**
>>>
--
Dr. Marc Hemberger
/\_/\
( o.o )
> ^ <
|\ _,,,---,, EMBL
ZZZzz /,`.-'`' -. ;-;;,_ C&N Group
|,4- ) )-,_. ,\ ( `'-' Meyerhofstr. 1
'---''(_/--' `-'\_) 69117 Heidelberg
Germany privat:
Marc.Hemberger@embl-heidelberg.de MHemberger@csi.com
** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:46 MET