Re: kqueue microbenchmark results
Dan Kegel wrote: ... Don't jump to conclusions. He's honestly trying to understand what the optimal interface would be. Let him catch up. Help him understand the requirements which motivated the kqueue design and why his proposed system call does not meet them. His role right now is to keep the kernel as simple as possible. You need to prove that his proposed interface is simpler than possible :-) A simple way to keep the kernel simple: http://linuxtoday.com/news_story.php3?ltsn=2000-12-09-013-20-NW-GN-KN :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
John Polstra wrote: In article [EMAIL PROTECTED], Jonas Bulow [EMAIL PROTECTED] wrote: John Polstra wrote: Actually I thought about this some more, and I'm not all that sure it's possible. I haven't actually _tried_ it, but I think you'd end up needing a low-level mutex around parts of the code. That would have to be implemented as a spinlock, which is exactly what we're trying to avoid in this exercise. What do you mean with low-level mutex? I mean, how low is low? :-) After doing some more thinking about the cmpxchgl-lock, it's quite hard to use it together with a technique involving the kernel. It will be a contradiction in many ways. I would be nice to have kqueue a EVFILT_MEM and wait for the contents of a memory adress contain a specific value (or other condition like threshold, range entrance/leaving). Then it can be used to wait for the adress used with cmpxchgl. Well, this was just thinking for this very moment. don't know it it's bad design to have rtld.c export lockdflt_init in the same way as dlopen, what di you think? Right, bad design. :-) just cheking.. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
John Polstra wrote: Jonas Bulow wrote Maybe I havn't been thinking enough but wouldn't this lock mechanism be a good choice to use for mmaped:memory accessed by multiple processes? It depends on the amount of contention you expect. The code in lockdflt.c was designed for a very low-contention situation (usually no contention at all). It also had to work in a very restrictive environment where the threads package was unknown and could be practically anything. Also it was designed to do locking between two threads running in the same process, which is not the problem you're trying to solve. Your environment is much more controlled, so you can probably do better. I think I'm trying to solve the threading-problem too. The overall architecture is a preforked server where there is a need to share information between all threads in all preforked processes. The solution below seems to be good if flock doesn't block all threads in a process, that is. I think the ideal solution would first try to lock the test-and-set lock, maybe spinning on it just a few times. If that failed it would fall back to using a system-call lock such as flock() which would allow the process to block without spinning. But I don't have any code to do that. (If you write some, could I have a copy?) I am about to. I don't know it it's bad design to have rtld.c export lockdflt_init in the same way as dlopen, what di you think? /jonas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
freebsd and non-preemtive threads
I'm trying to build a preforked and threaded server. When it comes to the threading part it seems that non-preemtive threads have a lot of benefits if the server is a statefull-server. What I'm trying to say is that the server is not going to do a lot of computation for each request. The server will simply update it's state and respond about it's success. In this situation preemtive threads creats more harm than good becuase of the fact that the thread don't know when the next context switch will happen and therefor must do locking and stuff for the resources it uses. I have found two packages for non-preemtive threads: "State Threads Library for Internet Applications", http://oss.sgi.com/projects/state-threads/ and GNU-Pth. Is there anyone who has any experience of these or have any comment about these? Is it possible to have the FreeBSD pthreads to be non-preemtive? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization
Wes Peters wrote: Jonas Bulow wrote: Ronald G Minnich wrote: I don't know about the "bsd" or whatever way. If you're doing real parallel programming and want real performance, you'll use a test-and-set like function that uses the low-level machine instructions for same. That is exacly what I'm looking for! I found it to be overkill to involve the kernel just because I wanted to have a context switch during the "test-and-set". Precisely how do you expect to "have a context switch" without "involving the kernel"? Sorry, I missed an important word in the sentence above, namely "not". I don't want to have a context switch during the test-and-set operation. Now, when I found the code in lockdflt.c (rtle-elf) that doesn't seem to be a problem. /j To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization
John Polstra wrote: If you want the "BSD way" you should probably create a 0-length temporary file somewhere and use the flock(2) system call on it. The file itself isn't important; it's just something to lock. I don't see any reason to do system calls just because I want to do an atomic operation (i.e aquire/release a lock). I found some really good code (:-)) in /usr/src/libexec/rtld-elf/i386/lockdflt.c that seems to do what I want. It's more the "i386"-way than the BSD-way. Maybe I havn't been thinking enough but wouldn't this lock mechanism be a good choice to use for mmaped:memory accessed by multiple processes? In lock_create the lock is aligned to CACHE_LINE_SIZE. Why is that important? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: R. Stevens select() Collisions Scenario
Alfred Perlstein wrote: Yes. :) When FreeBSD gets scheduler activations you'll be able to change to a single threaded process that will have excellent performance, the scheduler activations are just around the corner. Can you explain what scheduler activations are? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPC, shared memory, syncronization
What is the "BSD-way" of access to shared memory (mmap:ed) secure (avoid race conditions, etc)? Right now I'm using posix semaphores but I would like to know if there is a substitute like the way kqueue is for select/poll. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization
Jonas Bulow wrote: What is the "BSD-way" of access to shared memory (mmap:ed) secure (avoid race conditions, etc)? Right now I'm using posix semaphores but I would like to know if there is a substitute like the way kqueue is for select/poll. Hmm, I think I lost some word and deeper thought in my previous mail. :-) The problem is as follows: I have a couple of processes using a mmap:ed file as common data area. What I want to do is to make it safe for all processes to update data in this common memory area. I was thinking about using some part of the common data area for semaphores in some way. I just want a simple "test-and-set" operation I can use to make sure there is only one process writing to the common data area. To take the "test-and-set" further, I would like to make the process wait for the lock to be released. Can anyone give me hint how this is best implemented with FreeBSD as OS? I apology if this is not a pure FreeBSD related question but I could not find a better forum for this question. I could only find out solutions based on posix semaphores. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
UVM vs FreeBSD VM system
Hi, How does the UVM system compare to the VM system in FreeBSD? Are there any benchmark tests or research results in this area? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
