> In the example I provided the essential point is that there
> is *one* *correct* access pattern which is to read it once
> for each call to f(), to ensure that the same value is used
> everywhere in that function. Declaring this value volatile
> and taking a local copy does exactly the right thin
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea grammostola wrote:
Next thing what would be good to have imo is a good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I do
On 07/10/2011 10:08 AM, rosea grammostola wrote:
After spending a week using JackSession, I don't think a
quit-without-save option should be a 'showstopper' here Fons. Especially
because JackSession makes working with JACK so much easier. Better to
have JackSession without a quit-without-save opt
2011/7/10 rosea grammostola :
> On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
>>
>>
>> As to Jack Session support, I won't even consider it as long
>> as it doesn't support quit-without-save.
>> The rationale for not supporting this is IMNSHO completely bogus.
After playing around with it, I'm wi
> Ah. pthread_mutex_lock() / unlock(), as EXTERNAL functions, will never
> be optimized away or inlined. Now, being all sequence points, if you
> simply do
>
> pthread_mutex_lock();
> xval = x;
> pthread_mutex_unlock();
>
> the compiler is not allowed to move statements out the locked section
> o
> the hardware would be allowed to reorder them ... this is the reason why mutex
> implementations involve memory barriers ...
Yes, the hardware would be allowed to reorder them, so
pthread_mutex_lock() has memory barriers. I think everyone knew that
much :)
However my point to Fons was that, bec
> > the main problem is the lack of a memory model for multi-threaded
> > applications at the level of the language (c or c++). fortunately this
> > is about to change with c++0x and probably c1x.
>
> So in 10 years we will be able to rely on a conformant compiler being
> available on all relevant
On Sun, Jul 10, 2011 at 1:28 PM, Tim Blechmann wrote:
>> > the main problem is the lack of a memory model for multi-threaded
>> > applications at the level of the language (c or c++). fortunately this
>> > is about to change with c++0x and probably c1x.
>>
>> So in 10 years we will be able to rely
> >> > the main problem is the lack of a memory model for multi-threaded
> >> > applications at the level of the language (c or c++). fortunately this
> >> > is about to change with c++0x and probably c1x.
> >>
> >> So in 10 years we will be able to rely on a conformant compiler being
> >> availab
On 07/10/2011 06:33 PM, Emanuel Rumpf wrote:
2011/7/10 rosea grammostola:
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
As to Jack Session support, I won't even consider it as long
as it doesn't support quit-without-save.
The rationale for not supporting this is IMNSHO completely bogus.
Afte
Am Sun, 10 Jul 2011 17:08:32 +0200
schrieb rosea grammostola :
> On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
> > On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea grammostola wrote:
> >
> >> Next thing what would be good to have imo is a good software mixer with
> >> JackSession support. Unfortun
On Sun, Jul 10, 2011 at 06:05:45PM +0300, Dan Muresan wrote:
> Ah. pthread_mutex_lock() / unlock(), as EXTERNAL functions, will never
> be optimized away or inlined. Now, being all sequence points, if you
> simply do
>
> pthread_mutex_lock();
> xval = x;
> pthread_mutex_unlock();
>
> the compile
On Sun, Jul 10, 2011 at 5:14 PM, Fons Adriaensen wrote:
> On that I absolutely agree - cache coherency is the real
> problem, not pipelining. The latter should in fact be
> transparent from a language such as C/C++.
i may be way out of the loop, but having worked with some of the early
"massivel
On Sun, Jul 10, 2011 at 05:08:32PM +0200, rosea grammostola wrote:
> After spending a week using JackSession, I don't think a
> quit-without-save option should be a 'showstopper' here Fons. Especially
> because JackSession makes working with JACK so much easier. Better to
> have JackSession
On Sun, 10 Jul 2011 19:43:53 +0200
rosea grammostola wrote:
> On 07/10/2011 06:33 PM, Emanuel Rumpf wrote:
> > 2011/7/10 rosea grammostola:
> >> On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
> >>>
> >>> As to Jack Session support, I won't even consider it as long
> >>> as it doesn't support quit
Guys,
if you're writing code for your own use, and don't care about portability
or security, go ahead and use volatile as a synchronization primitive.
But if the code is going to be accepted into an open source project
that gets wide use, volatile is a bad idea. But don't take my word
for it; her
On Jul 10, 2011, at 2:41 PM, Paul Davis wrote:
On Sun, Jul 10, 2011 at 5:14 PM, Fons Adriaensen
wrote:
On that I absolutely agree - cache coherency is the real
problem, not pipelining. The latter should in fact be
transparent from a language such as C/C++.
i may be way out of the loop, but h
On Jul 10, 2011, at 6:34 PM, Sean Bolton wrote:
On Jul 10, 2011, at 2:41 PM, Paul Davis wrote:
do we have SMP systems these days that do not guarantee cache
coherency?
Yes. PowerPC and Alpha do not. UltraSPARC v9 and ARMv6/ARM11 and later
have modes where they do not (and linux on a SPARC v9
18 matches
Mail list logo
