axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lefrancois, Carl" <Carl.Lefranc...@axa-canada.com>
Subject RE : Multi-threading
Date Thu, 11 Dec 2008 15:56:12 GMT
Hello Patrick,

Manjula kindly provided a best-practice example for how to do
multi-threading with Axis2/C [1] (at least on the client side)  if I
remember correctly, it was one environment per thread, and the stubs
were per call?  Well in his example it is svc_client and not stub, but
if I understand correctly, those two concepts are one-to-one, meaning
one stub has one svc_client.

>From my point of view it seems the troubles you are encountering are
based in areas where Axis does little or nothing to help the programmer.
I have not seen any code to manage thread creation and resources acces
in the Axis2/C project.  Problems like resource deadlock on the
configuration file are outside the scope of what Axis2/C has to offer.

What Axis does well is freeing resources (once we figure out how to set
everything up right!) so I am a little confused as to where exactly the
limitations are.  You say the callback system provided is not good in
terms of freeing resources, but have you tried freeing your resources
from another function which itself waits for the callback to occur?
(either error callback or success callback)  I think this is the way
Axis was designed with as implied by Dimuthu: wait in a loop in your
main thread while the callbacks are outstanding, do no cleanup in the
callback itself, let that thread exit completely and after it is done,
then from your main thread detect that the callback ocurred and do the
cleanup there.  

For environment vs stub issues, there is no alternative but to take
ownership of this problem directly and implement some synchronisation
outside the scope of Axis2/C.  Your code synchronises creation of
threads and initialisation to avoid having deadlock problems.  Maybe
there is some improvement to be made to Axis here?  

My reason for responding though is really to comment on this phrase:
"Threads are a rather expensive resource to use for just waiting on an
IO completion".  It may be my lack of understanding, but I am pretty
sure that -- at least in the win32 tcp/ip stack -- once your thread goes
into asynchronous communication on a socket, you do not see it again
until there is some result.  This means if there is a timeout your
thread is inactive for a long time.  How can one thread wait on more
than one asychronous communication?  I admit this would be a far better
solution, however from my understanding of winsock2 it is not possible.

Seen this way, one thread per socket communication is maybe expensive in
resources, but it is the only way to ensure your main thread continues
to operate in a timely fashion.

Hth

Carl


[1] http://marc.info/?l=axis-c-user&m=118404667311058&w=2





-----Message d'origine-----
De : Patrick van Beem [mailto:patrick.van.beem@quintiq.com] 
Envoyé : jeudi, décembre 11, 2008 05:46
À : axis-c-dev@ws.apache.org
Objet : Multi-threading


Hello,

I'm experiencing serious limitations while using axis in a
multi-threading environment. I know axis is not fully designed (yet?)
for multi-threading, but I think some 'small' changes might make it more
usable. One can't deny multi-threading. Here my 2 cents:


* Callback and resources
In a multi-threading environment, an asynchronous job is often
responsible for freeing it's own resources (in this case, the
environment, the stub and possible extra application dependent data). In
the axis framework, this can't be done in the callback, since the
framework will use the stub after the callback is finished. This makes
it impossible for an application to free resources after a call has
finished (because you never know exactly when the call (including the
framework part of it) is finished. This makes the asynchronous
implementation of axis useless in a job-oriented multi-threading
environment. Improvements might include adding an extra callback to free
resources, that is made when axis has freed all its resources and does
not need any resources the user might free.


* Environment vs stub
Since every thread needs it's own environment and stub in axis and (as
stated above) in a multi-threaded environment a job is often responsible
of it's own resources, every job needs to allocate and initialize it's
environment and stub for each call (or keep one set initialized for
every thread, but that's not feasible when one thread can be used for
multiple purposes / jobs and/or threads can be added dynamically). And
free it after the job is finished. Apart from the (slight) performance
drawback, this poses another problem: Part of the stub initialization
includes reading the configuration file. When two threads try to do this
simultaneously, the last one who tries this, fails. Solutions to this
problem might include:
- Create a clone function for the stub, so all threads can clone from
template stub, instead of reading from disk.
- Separate the state information from the stub and put it in the
environment, so the stub can be used read-only and shared by threads.


* Async model
The asynchronous call implementation of axis is based on creating new
threads that just wait on a response. Threads are a rather expensive
resource to use for just waiting on an IO completion (and then
performing some small task). It might be better that the waiting on all
outstanding IO is done by one single thread. The work after the IO
completed can then be done by either that thread, or a (small and
static) thread pool. That way, no threads have to be created / deleted
on the flow, not more than one thread is waiting on IO and no high
amount of threads will exist when a lot of asynchronous calls exist in
parallel. My axis knowledge is not enough to see solutions for this
within axis right now.


What do you all think about these points?

Regards,

-- 

 
Patrick van Beem
Sr. Software engineer
 
Quintiq
 
T +31 (0) 73 691 07 39
F +31 (0) 73 691 07 54
M +31 (0) 06 15 01 65 83
E patrick.van.beem@quintiq.com
I www.quintiq.com



This message contains information that may be privileged or confidential
and is the property of Quintiq. It is only intended for the person to
whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute or use
this message or any part thereof. If you have received this message in
error, please notify the sender immediately and delete all copies of
this message. Please note that e-mails are susceptible to change,
therefore they are not binding.
  _____  

"Ce message est confidentiel, à l'usage exclusif du destinataire
ci-dessus et son contenu ne représente en aucun cas un engagement de la
part de AXA, sauf en cas de stipulation expresse et par écrit de la part
de AXA. Toute publication, utilisation ou diffusion, même partielle,
doit être autorisée préalablement. Si vous n'êtes pas destinataire de ce
message, merci d'en avertir immédiatement l'expéditeur."

"This e-mail message is confidential, for the exclusive use of the
addressee and its contents shall not constitute a commitment by AXA,
except as otherwise specifically provided in writing by AXA. Any
unauthorized disclosure, use or dissemination, either whole or partial,
is prohibited. If you are not the intended recipient of the message,
please notify the sender immediately."

Mime
View raw message