From: brian g. <bg...@po...> - 2002-02-02 21:12:45
|
hey guys, i've just changed all the c/c++ makefiles in Player so that CFLAGS is set _only_ in the top-level Makefile.common (just like Stage). makes it much easier to pick debug vs. optimized build. brian. |
From: Richard V. <va...@hr...> - 2002-02-06 23:09:33
|
folks, as you both warned me, the POSIX semaphores not work correctly when shared between processes. i was optimistic that the mmap was a work around, but i've pretty much determined that the sems are freezing or crashing player & stage. the higher the load on stage, the faster it crashes as a sem collision becomes more likely. crap. do you know any neat tricks to solve the problem? unless i/you have any great ideas i will bury a single SYSV sem under the locking functions again and wait for linus to come up with the goods on this one. R/ -- Richard Vaughan HRL Laboratories [va...@hr...] |
From: brian g. <bg...@po...> - 2002-02-07 00:04:38
|
Richard Vaughan scribed: > > > as you both warned me, the POSIX semaphores not work correctly when shared > between processes. i was optimistic that the mmap was a work around, but > i've pretty much determined that the sems are freezing or crashing player > & stage. the higher the load on stage, the faster it crashes as a sem > collision becomes more likely. crap. > > do you know any neat tricks to solve the problem? > > unless i/you have any great ideas i will bury a single SYSV sem under the > locking functions again and wait for linus to come up with the goods on > this one. > andrew and i have just been going over the possibilities, and the only thing that we can come up with is POSIX fcntl() record-locking. seems to be widely supported, and is the only POSIX way to do things, until LinuxThreads supports process-shared POSIX semaphores. you can either lock the whole mmap()ed file, or just the range you want (in order to increase concurrency just a bit). we think that it might be slower, but can't find any benchmark info. brian. |
From: Richard V. <va...@hr...> - 2002-02-07 00:20:53
|
I've come down on using BSD file locking for the time being. It's an easy replacement, and it'll still allow per-device locking. a quick check shows that flock(2) is pretty common. performance is not as good as semaphores but better than fcntl. i'm leaving the POSIX code in for when the kernel is ready for us... R/ On Wed, 6 Feb 2002, brian gerkey wrote: > Richard Vaughan scribed: > > > > > > as you both warned me, the POSIX semaphores not work correctly when shared > > between processes. i was optimistic that the mmap was a work around, but > > i've pretty much determined that the sems are freezing or crashing player > > & stage. the higher the load on stage, the faster it crashes as a sem > > collision becomes more likely. crap. > > > > do you know any neat tricks to solve the problem? > > > > unless i/you have any great ideas i will bury a single SYSV sem under the > > locking functions again and wait for linus to come up with the goods on > > this one. > > > > andrew and i have just been going over the possibilities, and the only thing > that we can come up with is POSIX fcntl() record-locking. seems to be > widely supported, and is the only POSIX way to do things, until LinuxThreads > supports process-shared POSIX semaphores. you can either lock the > whole mmap()ed file, or just the range you want (in order to increase > concurrency just a bit). > > we think that it might be slower, but can't find any benchmark info. > > > brian. > > -- Richard Vaughan HRL Laboratories [va...@hr...] |
From: brian g. <bg...@po...> - 2002-02-07 05:18:22
|
Richard Vaughan scribed: > > > I've come down on using BSD file locking for the time being. It's an > easy replacement, and it'll still allow per-device locking. a quick check > shows that flock(2) is pretty common. performance is not as good as > semaphores but better than fcntl. i'm leaving the POSIX code in for when > the kernel is ready for us... > hmmm...seems like we should use POSIX if we can; i.e., fcntl() locking. how much faster is flock()? also, where did you find performance info on the various things? i couldn't find anything. brian. |
From: Richard V. <va...@hr...> - 2002-02-07 19:34:44
|
i agree. looking around this morning it seems that flock() is out of style, and fcntl is very portable, so i'll replace it with fcntl. before either of you can tell me, i realized last night (i woke from my sleep with this in my head) that the fcntl/flock calls require open file descriptors, so the unique lock per device won't scale. dammit i'm disappointed with linux for the first time in ages! we need that POSIX shared sem functionality! i'll use a single fd for the clock device as the advisory lock. we'll get more lock collisions, but it'll scale. one thing that occurred to me is to kick off player as a thread inside stage. we'd need a thread entry point that works like player's main(). the possible name space collisions could make implementing this tedious, but swapping data between P & S would be eays peasy. just a thought for the record. R/ On Wed, 6 Feb 2002, brian gerkey wrote: > Richard Vaughan scribed: > > > > > > I've come down on using BSD file locking for the time being. It's an > > easy replacement, and it'll still allow per-device locking. a quick check > > shows that flock(2) is pretty common. performance is not as good as > > semaphores but better than fcntl. i'm leaving the POSIX code in for when > > the kernel is ready for us... > > > > hmmm...seems like we should use POSIX if we can; i.e., fcntl() locking. > > how much faster is flock()? also, where did you find performance info on > the various things? i couldn't find anything. > > > brian. > > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- Richard Vaughan HRL Laboratories [va...@hr...] |
From: brian g. <bg...@po...> - 2002-02-07 21:54:58
|
Richard Vaughan scribed: > > i agree. looking around this morning it seems that flock() is out of > style, and fcntl is very portable, so i'll replace it with fcntl. > > before either of you can tell me, i realized last night (i woke from my > sleep with this in my head) that the fcntl/flock calls require open file > descriptors, so the unique lock per device won't scale. dammit i'm > disappointed with linux for the first time in ages! we need that POSIX > shared sem functionality! i'll use a single fd for the clock device as the > advisory lock. we'll get more lock collisions, but it'll scale. > no, not really. as i understand it, another advantage to fcntl() (besides POSIX) is that you can do record locking, more properly called "range locking." that is, you specify an offset and length in bytes that you want to lock. i think that we can use a single fd for the whole mmap()ed area, and have P & S just lock the ranges that they are reading/writing. of course, locking a particular range could be more expensive than locking the whole file; we should find that out somehow. > one thing that occurred to me is to kick off player as a thread inside > stage. we'd need a thread entry point that works like player's main(). the > possible name space collisions could make implementing this tedious, but > swapping data between P & S would be eays peasy. just a thought for the > record. > yeah, then we could use POSIX mutexes. would take a little work though; maybe for a future release... brian. |
From: Richard V. <va...@hr...> - 2002-02-07 22:18:54
|
On Thu, 7 Feb 2002, brian gerkey wrote: > > no, not really. as i understand it, another advantage to fcntl() (besides > POSIX) is that you can do record locking, more properly called "range > locking." that is, you specify an offset and length in bytes that you > want to lock. i think that we can use a single fd for the whole mmap()ed > area, and have P & S just lock the ranges that they are reading/writing. you've forgotten the new device model - there is a file for each device - take a look in /tmp/stageIO.username.0 we could of course create a special lock file, where we lock the Nth byte to control access to the Nth object. that might work! R/ > of course, locking a particular range could be more expensive than locking > the whole file; we should find that out somehow. > > > one thing that occurred to me is to kick off player as a thread inside > > stage. we'd need a thread entry point that works like player's main(). the > > possible name space collisions could make implementing this tedious, but > > swapping data between P & S would be eays peasy. just a thought for the > > record. > > > > yeah, then we could use POSIX mutexes. would take a little work though; > maybe for a future release... > > brian. > -- Richard Vaughan HRL Laboratories [va...@hr...] |