<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<br>The compiler should, but it doesn't yet. For the next release I'm going to expose atomicLoad and atomicStore to deal with this until shared is fully implemented.</blockquote><div class="gmail_quote"><div><br>
</div>
<div>Thanks Sean</div><div><br></div><div>I have read some literature which says that shared variables should be declared volatile (in C++). But most people say that having mutex locks is sufficient and making variables volatile just adds to inefficiency.</div>

<div><br></div><div>Now I am not an expert in concurrency. I want to ask you this. Is it not sufficient just to mark critical code segments as synchronized? This is how things are in Java and with pthread library.</div><div>

<br></div><div>In my application, when I use shared variables (and since shared is transitive) I end up making most of my code synchronized. On top of that there is no way (that I know of) to use another lock/monitor than the class object itself with synchronized class methods (AFAIK this can be done with only synchronized code blocks). In my case being forced to use the class object as monitor/lock for all class methods is giving rise to lots of deadlocks.</div>

<div><br></div><div>So I am having a doubt on the practical aspect of shared variables. Would it not be nice to leave it to the users to decide which part of the code to declare synchronized -- and also leave the choice of lock/monitor too to the coder? Presently I see that synchronized methods have to be bound to the class object as a monitor and all the methods having a shared function argument must be declared synchronized method.</div>

<div><br></div><div>Thanks and Regards</div><div>- Puneet</div></div>