lkml.org 
[lkml]   [2007]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] rfc: threaded epoll_wait thundering herd
Date
On May 07, 2007, at 22:49:04, Ulrich Drepper wrote:
> On 5/7/07, Davide Libenzi <davidel@xmailserver.org> wrote:
>> read(2) is a cancellation point too. So if the fine userspace code
>> issues a random pthread_cancel() to a thread handling that, data
>> is lost together with the session that thread was handling.
>
> This is absolutely not comparable. When read/write is canceled no
> data is lost. Some other thread might have to pick up the slack
> but that's it.

Uhh, how can you claim "no data is lost" in this scenario:

A bunch of threads shares a common fd and fpos, reading fixed-size
records:

thread1: read(myfd, per_thread_buf, 512);
thread2: pthread_cancel(thread1);
thread3: read(myfd, per_thread_buf, 512);

This is *exactly* analogous to the epoll() scenario: A bunch of
threads are attempting to get data (either events or records) from a
given object. If thread1 gets cancelled after the completion of its
read() syscall then the file position will have been advanced but the
data in the per-thread buffer will be discarded. The third thread
won't (reliably) get the same data as thread1. It might get it
randomly on occasion if file position updates race, but you can't
rely on that behavior.

Here's how you make both of those models safe against thread
cancellation (assuming, of course, that process_one_buf has no
cancellation points until after it saves the buffer state somewhere):

char per_thread_buf[512];
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
while (read(fd, per_thread_buf, 512) == 512) {
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
process_one_buffer(per_thread_buf);
pthread_testcancel();
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
}
pthread_exit(NULL);
Look how trivial that is! Isn't it fun? Of course, once you look at
it this way you could do the same verbose crap that pthread_cancel/
pthread_setcancelstate/pthread_testcancel are doing with a simple int
protected by a pthread_mutex.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-05-08 05:59    [W:0.241 / U:0.052 seconds]
©2003-2011 Jasper Spaans. Advertise on this site