== Quote from Sean Kelly ([email protected])'s article > Adam Conner-Sax Wrote: > > > > 1) I couldn't get the synchronized class version (as opposed to using > > synchronized statements in the functions) to run. It would hang in odd > > ways. > > This may be related to a bug I reported earlier (and Sean was helpful > > enough > > to fix!) so this may be moot. > 'synchronized' as a class label may not be implemented in the compiler yet. > I'd stick to explicitly labeling methods are 'synchronized' for now.
I couldn't get that to work either. What does work is a "synchronized" block of code. That seems potentially more efficient also. > > 2) Message passing is slow in my tests. Often an order of magnitude or more > > slower than the fastest (lock-free queue). I expect to pay some price for > > the > > convenience, etc. but that seems excessive. > The limiting factor at this point is the cost of copying the Message struct around during processing. I've eliminated nearly all copies by passing by ref internally, but I believe an unnecessary copy or two may still remain. I'll see about tuning this further. Tuning the ctor and copy ops in Variant and Tuple would help as well, since nearly all the time spent is in those routines. For what it's worth, it's fairly easy to time this by building with -profile and having the main thread send messages to itself (since -profile doesn't yet work in multithreaded apps). Right. I've run into the multithreaded profiling issue. What you're describing makes sense: message passing has a much higher minimum time (7-8 us) than any of the others (1-2 us). That could be copying. I had thought it was some sort of wakeup to the receiver. The other methods just have a while loop waiting on new data rather than the blocking "receive" so I imagined there was some cost to waking up the receive thread. > > 4) I still don't totally understand shared. It does what I expect when > > variables are static. That's why all the queues are static objects. But > > that > > doesn't scale so well (I know I could set up static factories for static > > objects but that seems like it shouldn't be necessary). When I put an > > unshared variable in a non-static class and then use the class from multiple > > threads, the variable acts shared. Is that a bug or a feature? > Maybe you're just lucky? It's hard to reason about behavior without an > example. Maybe. I'd rather it not work this way (sharing even though not marked shared). Then I could put the queues into non-static structures and get the shared and TLS the way I expect. That would make using them from a spawned function a bit trickier but I think that could be handled. Thanks for the thoughts. Adam
