[Using OpenMp to Parallelize the source

[luis.seifert 10]

Hello Community, i was wondering why the Hecules isnot optimezed to use all the thread of the cpu...

Hands on that, i try by myself doing some mods at the source and got no problems while compiling and using the modified source to play, here is a example:
 

/src/char/char.c

original:

int mapif_sendall(unsigned char *buf, unsigned int len){	int i, c;	nullpo_ret(buf);	c = 0;	for(i = 0; i < ARRAYLENGTH(chr->server); i++) {		int fd;		if ((fd = chr->server[i].fd) > 0) {			WFIFOHEAD(fd,len);			memcpy(WFIFOP(fd,0), buf, len);			WFIFOSET(fd,len);			c++;		}	}	return c;}

parallel:

#include <omp.h>int mapif_sendall(unsigned char *buf, unsigned int len){	int i, c;	nullpo_ret(buf);	c = 0;		#pragma omp parallel reduction(+:c)  //reduction to prevent race condition on c		{			#pragma omp for schedule(static)  //will devide i/thread			for(i = 0; i < ARRAYLENGTH(chr->server); i++) {				int fd;				if ((fd = chr->server[i].fd) > 0) {					WFIFOHEAD(fd,len);					memcpy(WFIFOP(fd,0), buf, len);					WFIFOSET(fd,len);					c++;				}			}			}		return c;}

 

In a concurrent program, several streams of operations may execute concurrently. Each stream of operations executes as it would in a sequential program except for the fact that streams can communicate and interfere with one another. Each such sequence of instructions is called a thread. For this reason, sequential programs are often called single-threaded programs. When a multi-threaded program executes, the operations in its various threads are interleaved in an unpredictable order subject to the constraints imposed by explicit synchronization operations that may be embedded in the code. The operations for each stream are strictly ordered, but the interleaving of operations from a collection of streams is undetermined and depends on the vagaries of a particular execution of the program. One stream may run very fast while another does not run at all. In the absence of fairness guarantees (discussed below), a given thread can starve unless it is the only ``runnable'' thread.

 

So... Why not use? Just by respecting some rules and including one more library we can make a very efficient code with the same code... 

[Svanhild 2]

I noticed it as well, and I would agree to you. This is a great suggestion.