multithreaded to multiprocessing

multithreaded to multiprocessing

Post by Dhulipal » Thu, 20 May 2004 21:37:00


**** Post for FREE via your newsreader at post.usenet.com ****

Hi All,

I have a process in which 66 threads are running.In this there are some
threads which implemented SNMP Protocol, and some threads which
implemented HTTP protocol and some threads implemented Layer 2 switching

All the threads in HTTP or SNMP will communicate to the core switching
thru a set of library calls.

Since HTTP, SNMP are heavy processes.If some thing goes wrong(if there
is a core dump) in HTTP or SNMP threads, entire process will get effected.
Now if I have separate processes for HTTP and SNMP, problems in
SNMP/HTTP wouln't struck the core functionality of switching.

What is the approach I need to follow,to move all the SNMP related
threads under a single process and all HTTP threads under a nother process ?

What are the possible problems that we can expect ?

By the way I am not so good in linux programming.

Can you give me some resources/directions for doing this !!

Thanks and Regards
Suresh


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.yqcomputer.com/
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
 
 

multithreaded to multiprocessing

Post by Joe Seig » Thu, 20 May 2004 21:44:31


We can't do your learning curve for you. If you have specific questions
we can answer them. If you want instant general knowledge then you or
whoever you work for should hire an experienced threads programmer.

Joe Seigh

 
 
 

multithreaded to multiprocessing

Post by kamal » Fri, 21 May 2004 07:56:12


[snip]

Joe is looking for a consulting assignment:-)

regards
-kamal
 
 
 

multithreaded to multiprocessing

Post by Joe Seig » Fri, 21 May 2004 20:50:23


No comment. But the OP is clearly in over his head. It would interesting
to know how that came about. Incompetent staffing decision or something
else? Most of the regulars in c.p.t. would agree that threading skills
are under appreciated. It's bad enough having to use some of the *** software
out there that was clearly written by people who don't know what they're doing.
But to be asked to bail these guys out for free.

The original post mentioned HTTP, SNMP, and layer 2 switching. There's some
kind of load balencing going on but it's not clear what's providing the load
information. Splitting apart a multi-threaded program would be tricky even
if you knew what you were doing. You'd need a definite feel for detecting
what intra thread communication was going on, knowing what IPC mechanisms
would work, and what the consequences of adding restart semantics to a subset
of the threads would be. Can you write that down in 50 words or less for a newbie?

Joe Seigh
 
 
 

multithreaded to multiprocessing

Post by David Bute » Fri, 21 May 2004 23:06:20


Absolutely. For anyone who needs or thinks they want that "50 words or
less", the words are:

DON'T EVEN THINK OF TRYING IT

There. ;-)

--
/--------------------[ XXXX@XXXXX.COM ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.yqcomputer.com/ |
\----[ http://www.yqcomputer.com/ ]---/
 
 
 

multithreaded to multiprocessing

Post by Vincent Di » Wed, 26 May 2004 22:02:54

ith all respect,

Aren't 66 threads a bit overdone?

By the way when moving to multiprocessing, use shared memory to allocate.

If there is not enough shared memory in linux

( cat /proc/sys/kernel/shmmax )

then just login as root and put it higher :

echo 1000000000 > /proc/sys/kernel/shmmax

Now you can use up to 1G bytes for shared memory.


Use the shared memory to communicate between processes. You can lock easily
in linux (x86) here is for all oses i've got defined the defines. Use the
define NOASSEMBLY for x86-64 or Alpha etc :)

So you define somewhere :

lockvar lock_myself;

Now you can lock it with : Lock(lock_myself);
and after you did to your crucial work unlock is: Unlock(lock_myself);

Be sure you do not lock in a cacheline while other processes / threads write
in that cache line

safe is now :

#define CACHELINELENGTH 128

So lock variables, do put them in a seperated cacheline.

#if IRIX /* IRIX */

#if (_MIPS_SZLONG == 32)
#define Lock(v) {volatile unsigned long *tmpvar =
&((v).abi_lock); while (*tmpvar); spin_lock(&(v));}
#endif

#if (_MIPS_SZLONG == 64)
#define Lock(v) {volatile unsigned int *tmpvar =
&((v).abi_lock); while (*tmpvar); spin_lock(&(v));}
#endif

#define SlowLock(v) spin_lock(&v)
#define LockInit(v) init_lock(&v)
#define Unlock(v) release_lock(&v)
#define lockvar abilock_t

#elif MSVC /* windows NT */

#define lockvar volatile int
#define LockInit(v) ((v)=0)
#define Unlock(v) ((v)=0)

/* voor non-defined compilers onder windows: */
#if NOASSEMBLY

# define Lock(v) do { \
while(InterlockedExchange((LPLONG)&(v),1) !=
0); \
} while (0)
#else
__inline void LockA (volatile int *hPtr) {
__asm {
mov ecx, hPtr
la: mov eax, 1
xchg eax, [ecx]
test eax, eax
jz end
lb: mov eax, [ecx]
test eax, eax
jz la
jmp lb
end:
}
}
#define Lock(v) LockA(&(v))
#endif
#define SlowLock(v) Lock(&(v))

//#define Lock(v) {if(v){printf("was already
locked\n");StatusSMP();}else{v=1;}}

#elif IA64

//#define Lock(v) pthread_mutex_lock(&v)
//#define LockInit(v) pthread_mutex_init(&v,0)
//#define Unlock(v) pthread_mutex_unlock(&v)
//#define lockvar pthread_mutex_t

#define Lock(v) spin_lock(&v)
#define SlowLock(v) spin_lock(&v)
#define LockInit(v) spin_lock_init(&v)
#define Unlock(v) spin_unlock(&v)
#define lockvar spinlock_t

#else /* linux P6/PII/P3/K7 */
#define lockvar volatile int
#define exchange(adr,reg) ({volatile int _ret;asm volatile ("xchg
%0,%1":"=q"(_ret),"=m"(*(adr)):"m"(*(adr)),"0"(reg));_ret;})
#define LockInit(p) (p=0)
#define Unlock(p) (exchange(&p,0))
#define SlowLock(p) while(exchange(&p,1)) while(p)
#define Lock(p) while(exchange(&p,1)) while(p)
#endif





"Dhulipala" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
?


 
 
 

multithreaded to multiprocessing

Post by Hovik Meli » Tue, 28 Dec 2004 13:43:31


mechanisms

Ummmmmm... Can I? :)

Picture this. Someone comes to a socket ng and asks for help: he/she has a
package that communicates via pipes and he needs to have it work on a
network, without going into implementation details. The answer is simple:
replace popen() with socket() and Co. The rest would most probably work, if
it worked well via pipes. Plainly, less than 50 words, though pipes and
sockets are so different underneath.

Generally, no special skills are needed to comprehend sockets if you have
some basic idea on I/O, even though networking itself is such a mess, you
know. Are you going to explain to this guy, how Ethernet works physically,
or what is routing, or how TCP delivers data? Someone at some point "raised"
this to an abstraction level sufficient to forget about all underlying
complexities. Multithreading is different in that it is too crude and
relatively "young". Still no abstraction levels here!

So I'm just curous, does anyone at all think in this direction instead of
looking for consulting assignments? :) I.e. think of having some kind of a
MT framework that would allow to explain THAT in less than 50 words. Or am I
asking too much? :)

--
HM
 
 
 

multithreaded to multiprocessing

Post by stev » Tue, 28 Dec 2004 13:43:32

In article < XXXX@XXXXX.COM >,





Well, except that this is rather different. An application that communicates
using pipes still has well-bounded communication points. A multi-threaded
application, especially one that's doing so many different tasks inside
one process, is either of two things:
- Coming from flatland, where there's no memory protection, or
- has a large number of intimate connections between the threads that
probably aren't well documented.

The real answer to the original question is 100% dependent on the exact
architecture of the program. If it's a well-architected program that
is multithreaded only because it runs on some backward^Wflat-memory
"operating system"[1], then the probability of splitting it up is fairly
good.

But SNMP has a way of touching everything else in the system, and I
would guess that the interfaces for grabbing counters from the other
threads is "grab the global counter variable". All of that will need to
be separated out.


Probably the latter.

[1] Guess I'm feeling punchy about small executives today.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
 
 
 

multithreaded to multiprocessing

Post by Michael E. » Tue, 28 Dec 2004 13:43:33


HM > Date: Thu, 20 May 2004 21:34:52 +0500
HM > From: Hovik Melikyan < XXXX@XXXXX.COM >
HM > Newsgroups: comp.programming.threads
HM > Subject: Re: multithreaded to multiprocessing
HM >
HM >
[ ... ]
HM >
HM > Ummmmmm... Can I? :)
HM >
HM > Picture this. Someone comes to a socket ng and asks for help: he/she has a
HM > package that communicates via pipes and he needs to have it work on a
HM > network, without going into implementation details. The answer is simple:
HM > replace popen() with socket() and Co. The rest would most probably work, if
HM > it worked well via pipes. Plainly, less than 50 words, though pipes and
HM > sockets are so different underneath.

Have you been directly involved in converting an application from pipes into
using socket? Can you let me know what is this application so that I can avoid
it?


HM >
HM > Generally, no special skills are needed to comprehend sockets if you have
HM > some basic idea on I/O, even though networking itself is such a mess, you

Why do you think networking is a mess? It is the standardization's paradise.

HM > know. Are you going to explain to this guy, how Ethernet works physically,
HM > or what is routing, or how TCP delivers data? Someone at some point "raised"
HM > this to an abstraction level sufficient to forget about all underlying
HM > complexities. Multithreading is different in that it is too crude and
HM > relatively "young". Still no abstraction levels here!

Multithreading is almost as old as networking. It has been abstracted to
death since the early 70's.

HM >
HM > So I'm just curous, does anyone at all think in this direction instead of
HM > looking for consulting assignments? :) I.e. think of having some kind of a
HM > MT framework that would allow to explain THAT in less than 50 words. Or am I
HM > asking too much? :)

Don't panic! This is possible, and it will cost you approx. 1000$ / word.

Otherwise, just read introductory textbooks, take a degree in CS, read the
manuals, and start developing MT code YOURSELF.

HM >
HM > --
HM > HM

-MT

PS. Unless you are trying to post funny messages, your naive ``reasoning'' is
doing a disservice to yourself.




HM >
HM >
HM >
 
 
 

multithreaded to multiprocessing

Post by Hovik Meli » Tue, 28 Dec 2004 13:43:38


a
if
communicates

Of course it's too late to convert any existing MT app like that into
separate ST (or MT?) processes "easily".

I meant "simple as streams", but not literally. Maybe "simple as RPC", for
example, where you first write a program without even thinking about the
network. You only know there are some limitations wrt to data being
interchanged between the 2 parts of your system. Well, generally the rule is
"no pointers", the rest is a question of taste (the RPC architect's taste).
That's it. But again, this comparison is not for taking it literally.
Please, please, don't! :)

Just maybe, something like that for multithreading.

--
HM
 
 
 

multithreaded to multiprocessing

Post by Joe Seig » Tue, 28 Dec 2004 13:43:38


There is. It's called design patterns. But people usually write entire
books on the matter. I don't know if that's because it's the minimumally
economic unit of publication or not. You're welcome to try to explain all
the applicable thread design patterns and how to refactor code into those
patterns in 50 words or less. Assume the OP has no concept of threading
to begin with.

Starting now. The OP doesn't have forever. He has to get a product
out the door. :)

Joe Seigh
 
 
 

multithreaded to multiprocessing

Post by Hovik Meli » Tue, 28 Dec 2004 13:43:39


for
rule is
taste).

->



Ok, design patterns.

mov eax,a
cmp eax,b
jb L1
...

This is a typical way of comparing ints. But because you can easily, very
easily mess it up, you usually write:

if (a >= b)
...

at a higher abstraction level, that is.

Sockets are "higher" than Ethernet frames. RPC is even higher than sockets.
So high that it is relatively easy to change any of the underlying layers to
something different without affecting the main code.

It is possible to have an abstraction layer above any threading API that
would allow you to NOT think whether you create a process or a thread. That
layer would hide implementation of inter-whatever communication. If you
decide your pieces to be threads in one process, the system will be
efficient (but also "doomed to be" bug-free). For some reason, you may
decide to arrange your pieces into several processes, or to have one piece
per process.

This is very much possible, provided you have a framework for inter-...
communication with certain limitations (like in RPC, BUT NOT RPC). All in
all, you'd have a more reliable and simpler way of writing MT programs. MT
for masses, kind of :)

This has nothing to do with OP, and it is no longer a question to the ng.
Just thoughts. Ok? :)


That's probably an outsourcing way of "doing" software products (I'm
involved in as well).

--
HM
 
 
 

multithreaded to multiprocessing

Post by ptjm » Tue, 28 Dec 2004 13:43:45

In article < XXXX@XXXXX.COM >,


% It is possible to have an abstraction layer above any threading API that
% would allow you to NOT think whether you create a process or a thread.

There are optimizers which will take your code, which was written without
concern for threading, and figure out which bits which can be safely run
concurrently.

[...]

% If you decide your pieces to be threads in one process, the system will be
% efficient

Why? There's little or nothing about threading that inherently improves
performance. It is not uncommon for people to write code which can work
either as a multi-threaded program or a collection of processes, and finding
that the multi-threaded program is slower.

It seems to me that there's very little to abstract away. All the susv3
thread sychronisation primitives can be used between processes as well,
and the same is true for most of the synchronisation primitives in win32.
Beyond that, it's a question of how you use them. You can put whatever
abstraction layer you like around a global variable, but it's not going
to be shared between two processes unless you put it in shared memory.
--

Patrick TJ McPhee
East York Canada
XXXX@XXXXX.COM
 
 
 

multithreaded to multiprocessing

Post by Hovik Meli » Tue, 28 Dec 2004 13:43:55


I'm not aware of any reasons why a multithreaded application can be slower
on a single-CPU system than its multi-process counterpart.

At least starting/stopping processes takes much more time compared to
threads. Provided you have a well-designed application with minimal
interlocking, you gain both time and other system resources if you run it as
MT.


The abstraction layer can put globals wherever it finds appropriate (shared
or private memory) and hide the details from your main code.

--
HM
 
 
 

multithreaded to multiprocessing

Post by ptjm » Tue, 28 Dec 2004 13:43:56

In article < XXXX@XXXXX.COM >,


% I'm not aware of any reasons why a multithreaded application can be slower
% on a single-CPU system than its multi-process counterpart.

Who said anything about single-CPU systems? On single-CPU systems, we
sometimes see people complaining about multi-threaded code being slower
than single-threaded code. Anyway, however many CPUs you have, threading
introduces contention throughout the standard C library and that can
slow programs down.

% The abstraction layer can put globals wherever it finds appropriate (shared
% or private memory) and hide the details from your main code.

Sounds like overhead to me. Anyway, design it and we'll see what we
think of it, but in the abstract it doesn't sound terribly convincing.


--

Patrick TJ McPhee
East York Canada
XXXX@XXXXX.COM