mutex and loop

[gusti]

Hi,

I just begin my project which designed to work on multi thread environtment.Im guarding some block of loop using mutex, and some one on my team criticism that guarding a loop is not very good programming technique for applying threadsafeness. I need some clue and convincement if the program i wrote is bad.

Below is the illustration of program i wrote.
iterate() is program who do looping on link list and writing on socket, delete() delete element from link list and insert() insert element to linklist. Assume that any thread can access those 3 methods.

struct info {
	int a;
	int b;
};

typedef struct data {
	struct data* next;// pointer to link list
	struct info;
} data;

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
data globalData = { 0, { 0, 0 } };

void iterate() {
	pthread_mutex_lock(&lock);
	data * pdata = &globalData;
	while (data) {
		writeSocket(data);
		data = data->next;
	}
	pthread_mutex_unlock(&lock);
}

void delete() {
	pthread_mutex_lock(&lock);
	if (globalData.next != NULL) {
		data * d = globalData.next;
		globalData.next = d->next;
		free(d);
	}
	pthread_mutex_unlock(&lock);
}

void insert(data * d) {
	pthread_mutex_lock(&lock);
	if (globalData.next == NULL) {
		globalData.next = d;
		d->next = NULL;
	} else {
		d->next = globalData.next;
		globalData.next = d;
	}
	pthread_mutex_unlock(&lock);
}

The issues here is iterate() instead of making other thread blocked, also doing write on socket. Is it safe to do such IO operation on critical section block.

Pardon for my english

Best Regards

Gusti Andika

[kbw]

First, please use the code formatting tags as your code is unreadable as presented.

Your linked list should allow concurrent reads, but be blocked when inserting or removing entries. Your implementation blocks on all access.

Writing onto the sockedtshould be serialised too, but that's seperate from linked list matters.

[gusti]

Thanks for the response, just added code formatting to snippet.

Your linked list should allow concurrent reads, but be blocked when inserting or removing entries. Your implementation blocks on all access.

Does it means i dont have to use mutex when only read link list?

Writing onto the sockedtshould be serialised too, but that's seperate from linked list matters.

what it's mean with socket shold be serialized??

[jsmith]

You should not own the mutex during the writeSocket() call unless you can guarantee that the write will not block.

Assuming you remove the writeSocket() call from the linked list access mutex, you should still have a second mutex that prevents multiple concurrent writes (writeSocket calls). That is, writes to the socket should be done serially (serialized) rather than in parallel.

Also, unless you never plan to compile your code in C++, change the name of your delete() function, as delete is a reserved word in C++!

[gusti]

Hi Jsmith,

I still have some question hanging around in my head @_@!

You should not own the mutex during the writeSocket() call unless you can guarantee that the write will not block.

Can we make the writeSocket(or stdio read/write) not blocked programatically? does it mean to using like sigprocmask routine??

Is there any c routine call other than IO read write that could make my program blocked? If there is ,what c routine should i avoid to call inside critical section block? Is malloc() one of those routine?

Assuming you remove the writeSocket() call from the linked list access mutex, you should still have a second mutex that prevents multiple concurrent writes (writeSocket calls). That is, writes to the socket should be done serially (serialized) rather than in parallel.

let's say that there is 100 element in my list , do i have to create 100 mutex to prevent multiple concurent writes on the element? Will the number of mutex i use in program will affected my program performance?



Regards

Gusti Andika

[kbw]

One problem is if the threads attempt to write simultaneously, you can't be sure what will appear on the stream. If multiple calls to write occur, you may be context switched between them, so you have to guarantee that the writes occur completely one at a time.

The second problem is if the write blocks for some reason, it will slow down your iterate function. This may be ok, or it may not be. It it isn't you're probably better of having yet another thread that manages writing. So the iterate function would submit data, which is queued, and the write socket thread works thru the queue.

You can't predict what will slow your program, but they're usually external to your program or machine. Avoiding functions won't help as you're probably running on an OS which has preemptive multi-threading.

[gusti]

Let's i modify a little bit of my program, assume that the write socket is already serialized. And beside writing to socket there's a need to read a socket too.On read socket not need to modify list element only need to read some data.
is it safe to have one thread for writing socket and another thread for reading the socket? Or one thread for write socket and many thread for reading socket??

Regards

Gusti

[kbw]

That's fine.

[jsmith]

But the effects of having multiple simultaneous readers is somewhat undefined, in that only one thread will read data from the socket when it arrives, and which thread is the one is not defined.

[kbw]

Quite right. I was wrong earlier.

The common thing is to have some thread do the reads and dispatch the data to other threads/objects as required.

[quant]

hello every1,
I've question related it. I want to create a new socket in another thread(parallel) while well use in the main thread global loop of my daemon.

i.e. I can make a new socket and do not stop main global loop?