Re: Functions without side-effects. Proposal
On Sep 11, 9:58? am, Zara <me_z...@dea.spamcon.org> wrote:
[snip]
3.- Creating a frame to work in multhreaded/multicored environments
One of the main aims of goog multi-x programming is minimizing the
locks between different ? threads. To achieve this, we may use the
suggested paradigm of using an objets volatile interface to lock it
and then access it through the usual const/non-const interface.
Pure functions then would be limited to work with non-locking objects,
thus giving us assurance of its non-locking nature.
For instance, we may have:
? ? ObjectType some_thing;
? ? volatile ObjectType some_other_thing;
? ? ObjectType some_fun() pure {
? ? ? ? return some_thing;
? ? }
? ? ObjectType some_other_fun(const ObjectType& object) pure {
? ? ? ? return some_other_thing=object;
? ? }
? ? void thread_loop () {
? ? ? ? for(;;) {
? ? ? ? ? ? ? // lockless part
? ? ? ? const ObjectType newObject=some_fun();
? ? ? ? // probably locking part
? ? ? ? ? ? ? static_cast<void>(some_other_fuin(newObject);
? ? ? ? }
? ? }
If need arises to share some_thing with other thread, it should be
retyped as 'volatile ObjectType', and the compiler would issue an
error, because some_fun cannot be pure.
This might give us an extra tool to build correct programs and check
them at compile-time.
Now, I have read occasionally about using volatile to overload an
interface for thread safety, but I always felt it was intended as a
toy example and not for actual use. Do people actually use volatile
for anything except platform specific code to access memory mapped I/
O?
(I know my company has a high performance high volume sorting
algorithm which abuses volatile as a synchronization primitive. I
recall it breaking on a new processor a customer was using, so we had
to go and put in actual memory barriers.)
Overloading an interface using volatile to provide a thread safe
interface seems less desirable, because all of the primitive accesses
will be volatile accesses, presumably greatly inhibiting the compiler.
I suppose in each volatile member function, you could first lock, then
cast this to non-volatile and call the wanted member function. It just
seems not clean... I'd be curious on replies to this.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]