[boost] Re: Library Proposal: Event-Driven Values
Roland Richter wrote:
Dear Nicolas,
sorry for the late reply. Some other projects try to keep me busy.
And sorry for the late answer, I was in vacation
First, I'd like to mention that in German-speaking countries, EDV
is a very common acronym for "Elektronische Datenverarbeitung"
("electronic data processing"), hence the library name might be
somewhat confusing.
Noted. I'm rewriting the library with a much simpler interface and
overloading operators instead of all these sum_, diff_, etc. values and
I expect the name to make less sense in the end.
I think that your ideas lead into two rather different directions,
depending on whether these "event-driven" values
(a) actively update their related values whenever changed, or
(b) are passive and do nothing until their value is fetched.
Agree. I'm interested in the a) for my part, since I want the use of
these values in widgets, for example, to be passive. I mean to never
check for a change in a value, but instead connect a signal to a
callback for each change. With my (modest) experience, it's far less
resource-consuming.
However, I think there's a place for the b) case, and the complicity
between the two ways should be maximised.
[...]
I totalle agree with your examples, and that's the syntax I realized was
the best few weeks after my post.
For a symbolic math package in C++, I'd point you to http://www.ginac.de
I'll take a look. Thx.
I guess, however, that your main interest lies in variant (a),
"event-driven" (opposed to "lazy evaluated") values, that is, in
implementing some special form of the Subject/Observer pattern,
based on boost::signals.
Exactly.
For reasons I pointed out above, this would just make sense if your
main focus is *not* on updating other values, but on triggering some
action, like this:
void print_me( int i )
{
std::cout << i << std::endl;
}
value i( 6, print_me );
i = 42; // Prints 42 to stdout.
In other words, value would be some type where construction,
assignment, and maybe destruction would call some signals. This might
include, but is not limited to, updating other values.
The current version have a signal for value change and destruction. I
could also add a signal for "redefinition" (or assignment). The
value-change signal minimizes the updates (I assume we are talking about
the non-lazy values). The shortcut of passing a callback directly in
the constructor could be a good idea.
Such a class might indeed be helpful, because notifications often occur
if a value has changed; so this would simplify things. However, I doubt
whether it pays off to invent all those sum_, diff_, sync_,
and_so_on_value's
in an "event-triggers-update-of-values" way.
I agree. Some "stuff"_value remains for now, but could be removed also.
For example, the ostringstream_value:
ostringstream_value str;
value i(4), j(6);
str << i << " << " << j << " => " << (i << j) << '\n';
For now, it's simpler for me to have a subtype, but partial
specializations or policies could also be used.
Regards,
Nicolas
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
Alexander Terekhov wrote: Nicolas Fleury wrote: [...] Would it be possible to post some code that "experience has shown" to be error-prone using semaphores comparing with conditions/mutexes? Sure... thanks to the Microsoft Corp. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_metrsect.asp Take a look at their brain-damaged "metered section" semaphore implementation. Note that MS "auto-reset event" is nothing but a binary sema (well, brain-dead "pulsing" aside for a moment). Thx for the link, but I don't get it. How is Microsoft implementation of semaphore is showing that all implementations of semaphore should be avoided? Using semaphores versus using mutexes/conditions should be illustrable with few lines of code. I just want to understand what some developers think is error-prone about semaphores, whatever the implementation (or with the removed boost implementation). Thx. Regards, Nicolas Fleury ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
Alexander Terekhov wrote: Stefan Seefeld wrote: [...] I'm still not convinced. http://google.com/groups?selm=3CED3306.DF6DB829%40web.de (Subject: Re: many semaphores) Would it be possible to post some code that "experience has shown" to be error-prone using semaphores comparing with conditions/mutexes? Some code illustrating the problem with semaphores would be useful, and could maybe be added to the currently very short justification in Boost.Thread faq. Thx Regards, Nicolas Fleury ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
William E. Kempf wrote: Stefan Seefeld said: As boost doesn't, there must clearly be other reasons for them not to do that. There is, but the explanations are long and quite complex. That's why the FAQ points you at a seminal paper on the subject, rather than attempting Correct me if I'm wrong, but isn't the FAQ pointing to a seminal paper only when justiying the absence of events, not semaphores? What is the paper you have in mind to justify the absence of semaphores? I would like very much to understand and be convinced. It would also be nice if the #10 of the FAQ would point to this paper. to explain it. Like I've said in numerous arguments about the Event concept, the problem with the concept isn't that it's broken or unusable, only that it's difficult to actually use correctly. Most users think their code is correct, when in fact they have race conditions waiting to bite them. When Mutexes and Condition variables provide everything that Semaphores and Events do, but in a way that's easier to use correctly, the choice to not include Event's or Semaphore's is reasonable. I highly respect and esteem people working on boost, and I strongly expect the removal of semaphore was reasonable. It's just that the current explanation I see is not convincing for me and probably others: "Semaphore was removed as too error prone. The same effect can be achieved with greater safety by the combination of a mutex and a condition variable." I guess the answer is in the papers referred in the events versus conditions question; it's just that people coming from Posix environments would not care about the event topic and would feel the semaphore absence justification is incomplete. Regards, Nicolas Fleury ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
Alexander Terekhov wrote: Nicolas Fleury wrote: Thx for the link, but I don't get it. How is Microsoft implementation of semaphore is showing that all implementations of semaphore should be avoided? It is showing that semas (e.g. bin-semas aka "auto-reset events") are really error-prone. Their implementation of counting semaphore How? using a mutex (well, they actually use a totally brain-damaged "dying spinlock") plus a binary semaphore is buggy (it contains erroneous synchronization). Now... you might to follow this link: Why buggy? "Pthreads win32 is just trying to be a general pupose condition variable as defined by the pthreads standard, suitable for any and all threads to go around calling pthread_cond_wait() and pthread_cond_signal() on. As a consequence the implementation contains several mutexes, semaphores etc, and a flow of control that will make your brains dribble out of your ears if you stare at the code too long (I have the stains on my collar to prove it ;-). Such are the joys of implementing condition variables using the Win32 synchronization primitives!" But what's the relation between Microsoft implementation of semaphore, pthread win32 implementation of condition and the error-proness of semaphores versus mutexes/conditions in general? Is it simply a mather of preference and style, or is there a simple case to show why semaphores are error-prone instead of mutexes/conditions? Regards. Nicolas Fleury ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Are signals order same across platforms?
Hi, I know we shouldn't assume the order of signals execution, but can we assume it will be the same on all platforms, whatever that order is? It would be a big plus for unit testing. Thanks Nicolas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
