Re: [Vala] volatile variable
On Tue, 2014-06-17 at 08:20 +0200, Jürg Billeter wrote: > On Tue, 2014-06-17 at 01:38 +0200, Maciej Piechotka wrote: > > On Mon, 2014-06-16 at 10:55 +0800, Nor Jaidi Tuah wrote: > > > Summary: byte access (read/write) is atomic on > > > MOST architectures. Dang! I thought ALL. > > > > > > > I'm not sure but there is no guarantee that it is - you don't know it it > > will be, say, in ARMv9. Alpha, while probably not in the top 3 most > > popular ISA on the world, is a strange architecture. > > I'm not aware of any modern CPU where aligned loads or stores (up to > machine word size) are not atomic. While Alpha has no ordering > guarantees, aligned loads and stores are still atomic, as far as I know. > I don't see this changing in the foreseeable future for general purpose > CPUs. You still have to be very careful about reordering issues, though. > > Regards, > Jürg > Thanks for clarification. As I wrote I wasn't 100% sure about Alpha, and I don't have one around to play with it ;) Best regards signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Tue, 2014-06-17 at 09:07 +0800, Nor Jaidi Tuah wrote: > Thank you for all the feedback and discussion. > I now realize that my app, which seems to work > perfectly, is a time bomb that would blow > my brain away because I'm using a "pipeline" > where a finished job is indicated by setting > a flag as the final instruction. Like this: > > . > // do stuff > . > // and finally > flag = flag_val; > // WRONG. Can be reordered even if > // atomicity can be assumed > > I have to put a barrier to ensure that the flag > setting is REALLY the final instruction. Can > I do this? > > . > // do stuff > . > // and finally > AtomicInt.@set (ref flag, flag_val); > // Safe > > What's the correct way to do this in vala? > > > Nice day > Nor Jaidi Tuah > It should be safe with respect to setting flag. The AtomicInt.@set will not be reordered neither by the compiler nor by processor. Best regards signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Tue, 2014-06-17 at 01:38 +0200, Maciej Piechotka wrote: > On Mon, 2014-06-16 at 10:55 +0800, Nor Jaidi Tuah wrote: > > Summary: byte access (read/write) is atomic on > > MOST architectures. Dang! I thought ALL. > > > > I'm not sure but there is no guarantee that it is - you don't know it it > will be, say, in ARMv9. Alpha, while probably not in the top 3 most > popular ISA on the world, is a strange architecture. I'm not aware of any modern CPU where aligned loads or stores (up to machine word size) are not atomic. While Alpha has no ordering guarantees, aligned loads and stores are still atomic, as far as I know. I don't see this changing in the foreseeable future for general purpose CPUs. You still have to be very careful about reordering issues, though. Regards, Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
Thank you for all the feedback and discussion. I now realize that my app, which seems to work perfectly, is a time bomb that would blow my brain away because I'm using a "pipeline" where a finished job is indicated by setting a flag as the final instruction. Like this: . // do stuff . // and finally flag = flag_val; // WRONG. Can be reordered even if // atomicity can be assumed I have to put a barrier to ensure that the flag setting is REALLY the final instruction. Can I do this? . // do stuff . // and finally AtomicInt.@set (ref flag, flag_val); // Safe What's the correct way to do this in vala? Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Mon, 2014-06-16 at 10:55 +0800, Nor Jaidi Tuah wrote: > Summary: byte access (read/write) is atomic on > MOST architectures. Dang! I thought ALL. > I'm not sure but there is no guarantee that it is - you don't know it it will be, say, in ARMv9. Alpha, while probably not in the top 3 most popular ISA on the world, is a strange architecture. Also note the difference between atomicity and synchronization. Most higher level languages exposes "atomics" which are sequentially consistent (in short not only the reads/writes are not 'corrupted' the processor behaves as if they were performed in order they happen in thread). However what some people mean by "atomic" is often much weaker - it just guarantees that value is not corrupted. So aligned loads/stores are atomic in second sense (on most if not all architectures) but not in the first one. > > [1] Synchronized means if x and y are set to 0 and thread 1 sets first x > > and then y to 1 then thread 2 might read y == 1 and then x == 0. Atomic > > means that state of x and y are either 0 or 1. Note that x86 is rather > > strongly order architecture so you won't notice it in _most_ > > circumstances on that platform but you can get the reordering on for > > example arm. Programmers manual from processors should have a few pages > > in them stating the exact rules. > > Don't forget the compiler. It too can reorder. > Well. That's the only reordering that volatile is suppose to prevent. I.e. if stores to volatile happens in x y order in code they happen in x y code in assembly. For example imagine printer controller - reversing those statements would have different effect[1]. # Location in memory where the page is located registers[print_page_buffer] = ptr # Do print contents registers[print_do_print] = 1 However that's true - compiler do reorder the code as well as happily breakes a perfectly 'fine' code that was supposed to work[2]. Best regards [1] Memory mapped I/O are in uncached memory as specified by page table/control registers/ so the question about cache hierarchy and processor reordering do not play a role here as processor already knows it's not suppose to reorder for this memory. [2] http://blog.regehr.org/archives/918 signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Mon, 2014-06-16 at 11:51 +0800, Nor Jaidi Tuah wrote:
> > [1] Note that because the libgee deals with pointers it needs to
> > implement a bit more. If you need a guide see
> > http://blog.piechotka.com.pl/2014/03/01/lock-free-collection-in-libgee-hazard-pointer/
> > (even more self-promotion)
> >
>
> Thanks for the link. That eventually leads me to
> ConcurrentList. I can't use ConcurrentList directly
> because I need these:
>
>void insert_after (G ref_item, G item)
>G get_after (G ref_item)
>
> In non-threaded code, the above can be implemented using
>
>insert (index_of (ref_item) + 1, G);
>get (index_of (ref_item) + 1)
>
> In multithreaded code, these won't work without locks.
>
> Even though I cannot use ConcurrentList directly,
> I hope I can learn something useful from it.
>
>
> Nice day
> Nor Jaidi Tuah
I don't want to worry you too much but what you need is a lock-free
list. While writing one is possible (ConcurrentList is a single-linked
lock free list) it's not a trivial exercise (I'd give it a few weeks at
least).
A good news is that you could use a ConcurrentList - if you have an
iterator you can access the next element and insert the element after
the current one:
ListIterator? find(List g, EqualFunc eq, G item) {
var iter = g.list_iterator ();
if (!iter.foreach ((i) => {return !eq (i, item);})) {
return iter;
} else {
return null;
}
}
bool insert_after(List g, EqualFunc eq, G item, G to_insert) {
var iter = find (g, eq, item));
if (iter != null) {
iter.add (to_insert);
return true;
} else {
return false;
}
}
bool get_after(List g, EqualFunc eq, G item, out G? after) {
var iter = find (g, eq, item));
if (iter != null && iter.next ()) {
after = iter.get ();
return true;
} else {
after = null;
return false;
}
}
Both should be atomic. You might want to cache iterator as well (it
depends on your use-case). However locks might be faster as well
depending on your use-case.
Best regards
signature.asc
Description: This is a digitally signed message part
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
> [1] Note that because the libgee deals with pointers it needs to > implement a bit more. If you need a guide see > http://blog.piechotka.com.pl/2014/03/01/lock-free-collection-in-libgee-hazard-pointer/ > (even more self-promotion) > Thanks for the link. That eventually leads me to ConcurrentList. I can't use ConcurrentList directly because I need these: void insert_after (G ref_item, G item) G get_after (G ref_item) In non-threaded code, the above can be implemented using insert (index_of (ref_item) + 1, G); get (index_of (ref_item) + 1) In multithreaded code, these won't work without locks. Even though I cannot use ConcurrentList directly, I hope I can learn something useful from it. Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
Summary: byte access (read/write) is atomic on MOST architectures. Dang! I thought ALL. > [1] Synchronized means if x and y are set to 0 and thread 1 sets first x > and then y to 1 then thread 2 might read y == 1 and then x == 0. Atomic > means that state of x and y are either 0 or 1. Note that x86 is rather > strongly order architecture so you won't notice it in _most_ > circumstances on that platform but you can get the reordering on for > example arm. Programmers manual from processors should have a few pages > in them stating the exact rules. Don't forget the compiler. It too can reorder. Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Mon, 2014-06-16 at 08:44 +0800, Nor Jaidi Tuah wrote: > > As a side question - why do you need volatile? In most cases it's not > > needed (unless you write kernel/driver and do memory based I/O). > > My multithreaded code didn't work and I thought > may be gcc is making a wrong optimization. > Turns out to be my own fault. > > But still, I'm curious, can gcc make a wrong > optimization not knowing that a variable may > be changed by another thread? > > I notice that both glib and vala use volatile ref_count. > So, if we were to do our own application-specific > memory management, shouldn't we have volatile > somewhere? > > > Nice day > Nor Jaidi Tuah > Well the volatile ref_count is not accessed as volatile - it's accessed as atomic via GLib.Atomic.int_add and similar functions. If you want to use atomics see libgee code for usage[1] (yes, I know - shameless self-promotion) - note that atomic code can become hard easily. Best regards [1] Note that because the libgee deals with pointers it needs to implement a bit more. If you need a guide see http://blog.piechotka.com.pl/2014/03/01/lock-free-collection-in-libgee-hazard-pointer/ (even more self-promotion) signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Mon, 2014-06-16 at 09:18 +0800, Nor Jaidi Tuah wrote: > > True - there is a few cases where volatile can be used (I know too > > little about security to say if using just volatile is ok from standard > > POV). I guess you could reformulate my question into - "in most you > > don't need volatile and many programmers use volatile as atomic despite > > it does not mean that. Are you sure that your use case is legitimate?". > > I have one use case which may not be legitimate > academically (whatever that means), but in > practice should be ok. I assume that access to > a byte is always atomic and so I don't have to > use a lock or other sync mechanisms. I think > this is reasonable if my routine can tolerate > cache delay (one thread already updating, another > thread still using the old value). But I still need > to tell the compiler to suppress its optimization, > hence volatile. > In many cases "not legitimate academically" means "not according to C standard and may not work on current or future architectures with current or future compilers". On most architectures align access should be indeed atomic but I am not 100% sure about, for example, Alpha. Also note that load and store are atomic - not for example addition. Note however that the accesses are atomic but not synchronized[1]. Note that you don't need lock or sync - you just need to use an atomic. GLib has support for sequential consistent atomics by default and when you will have access to C11 compiler you will have proper access to other ordering starting with relaxed (no synchronization - only atomicity) ending with sequential consistency. Note that the atomics tend to be 'hard' to reason about once you go below sequential consistency as you have the memory synchronization relaxed - see this 3h talk about _basics_ of the C++11 memory model if you want to know more - http://channel9.msdn.com/Shows/Going +Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2. Two things to know: - Most people got the requirements for reference counting wrong IIRC - IIRC There is a small error in explanation about fences vs. atomics (I'd have to goggle it again to find what exactly is the problem) Note that reasoning deal with memory _ordering_ not delay as the thread model allows infinite suspension of any thread, so the memory can be indeed delayed indefinitely. Best regards [1] Synchronized means if x and y are set to 0 and thread 1 sets first x and then y to 1 then thread 2 might read y == 1 and then x == 0. Atomic means that state of x and y are either 0 or 1. Note that x86 is rather strongly order architecture so you won't notice it in _most_ circumstances on that platform but you can get the reordering on for example arm. Programmers manual from processors should have a few pages in them stating the exact rules. signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
> True - there is a few cases where volatile can be used (I know too > little about security to say if using just volatile is ok from standard > POV). I guess you could reformulate my question into - "in most you > don't need volatile and many programmers use volatile as atomic despite > it does not mean that. Are you sure that your use case is legitimate?". I have one use case which may not be legitimate academically (whatever that means), but in practice should be ok. I assume that access to a byte is always atomic and so I don't have to use a lock or other sync mechanisms. I think this is reasonable if my routine can tolerate cache delay (one thread already updating, another thread still using the old value). But I still need to tell the compiler to suppress its optimization, hence volatile. I think my use case is valid unless 4-bit processors are coming back. Or, unless cache delays are indefinitely long. Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
> /* Need to register types with the glib type system for dynamic
> * construction with gtkbuilder. Need to figure out a better way
> * to ensure the calls to typeof() are not optimized out.
> */
>
> stdout.printf("Registering %s\n", typeof(AboutDialog).name());
> stdout.printf("Registering %s\n", typeof(AddSimulationDialog).name());
Thanks for the tip. I'm still using the --debug flag
and so this issue is still dormant in my code.
But I am changing it right now so it won't bite me
later.
Nice day
Nor Jaidi Tuah
PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you
are neither the addressee (intended recipient) nor an authorised recipient of
the addressee, and have received this message in error, please destroy this
message (including attachments) and notify the sender immediately. STRICT
PROHIBITION: This message, whether in part or in whole, should not be reviewed,
retained, copied, reused, disclosed, distributed or used for any purpose
whatsoever. Such unauthorised use may be unlawful and may contain material
protected by the Official Secrets Act (Cap 153) of the Laws of Brunei
Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam,
accept[s] no responsibility for loss or damage arising from the use of this
message in any manner whatsoever. Our messages are checked for viruses but we
do not accept liability for any viruses which may be transmitted in or with
this message.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Mon, 2014-06-16 at 02:29 +0200, Paul Marques Mota wrote: > 2014-06-15 1:20 GMT+02:00 Maciej Piechotka > : > > > On Wed, 2014-06-11 at 16:54 +0800, Nor Jaidi Tuah wrote: > > > Is there any way to declare a volatile? > > > > As a side question - why do you need volatile? In most cases it's not > > needed (unless you write kernel/driver and do memory based I/O). > > > > Or unless you write password management code. See > https://www.securecoding.cert.org/confluence/display/seccode/MSC06-C.+Beware+of+compiler+optimizations > > Regards, True - there is a few cases where volatile can be used (I know too little about security to say if using just volatile is ok from standard POV). I guess you could reformulate my question into - "in most you don't need volatile and many programmers use volatile as atomic despite it does not mean that. Are you sure that your use case is legitimate?". Regards signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Sun, 2014-06-15 at 11:39 -0700, Edward Hennessy wrote:
> On Jun 14, 2014, at 4:20 PM, Maciej Piechotka
> wrote:
> >
> > As a side question - why do you need volatile? In most cases it's not
> > needed (unless you write kernel/driver and do memory based I/O).
> >
>
> I've run into the issue calling functions with side effects. Here is a
> snippet of my code with the workaround:
>
>
> /* Need to register types with the glib type system for dynamic
> * construction with gtkbuilder. Need to figure out a better way
> * to ensure the calls to typeof() are not optimized out.
> */
>
> stdout.printf("Registering %s\n", typeof(AboutDialog).name());
> stdout.printf("Registering %s\n", typeof(AddSimulationDialog).name());
> stdout.printf("Registering %s\n",
> typeof(ArchiveSchematicsDialog).name());
> stdout.printf("Registering %s\n", typeof(ExportBOMDialog).name());
> stdout.printf("Registering %s\n", typeof(ExportNetlistDialog).name());
> stdout.printf("Registering %s\n", typeof(NewDesignDialog).name());
> stdout.printf("Registering %s\n", typeof(NewProjectDialog).name());
> stdout.printf("Registering %s\n",
> typeof(RenumberRefdesDialog).name());
> stdout.printf("Registering %s\n", typeof(ResetRefdesDialog).name());
> stdout.printf("Registering %s\n",
> typeof(BackannotateRefdesDialog).name());
>
> Cheers,
> Ed
Technically that's workaround of a workaround. C compiler should not
optimize it but we promised that this time about_dialog_get_type ()
really is a pure function.
Probably a better way is typeof(AbountDialog).class_ref() ot
typeof(AboutDialog).class_peek().
Regards
signature.asc
Description: This is a digitally signed message part
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
> As a side question - why do you need volatile? In most cases it's not > needed (unless you write kernel/driver and do memory based I/O). My multithreaded code didn't work and I thought may be gcc is making a wrong optimization. Turns out to be my own fault. But still, I'm curious, can gcc make a wrong optimization not knowing that a variable may be changed by another thread? I notice that both glib and vala use volatile ref_count. So, if we were to do our own application-specific memory management, shouldn't we have volatile somewhere? Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
2014-06-15 1:20 GMT+02:00 Maciej Piechotka : > On Wed, 2014-06-11 at 16:54 +0800, Nor Jaidi Tuah wrote: > > Is there any way to declare a volatile? > > As a side question - why do you need volatile? In most cases it's not > needed (unless you write kernel/driver and do memory based I/O). > Or unless you write password management code. See https://www.securecoding.cert.org/confluence/display/seccode/MSC06-C.+Beware+of+compiler+optimizations Regards, -- Paul ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Jun 14, 2014, at 4:20 PM, Maciej Piechotka wrote:
>
> As a side question - why do you need volatile? In most cases it's not
> needed (unless you write kernel/driver and do memory based I/O).
>
I've run into the issue calling functions with side effects. Here is a snippet
of my code with the workaround:
/* Need to register types with the glib type system for dynamic
* construction with gtkbuilder. Need to figure out a better way
* to ensure the calls to typeof() are not optimized out.
*/
stdout.printf("Registering %s\n", typeof(AboutDialog).name());
stdout.printf("Registering %s\n", typeof(AddSimulationDialog).name());
stdout.printf("Registering %s\n",
typeof(ArchiveSchematicsDialog).name());
stdout.printf("Registering %s\n", typeof(ExportBOMDialog).name());
stdout.printf("Registering %s\n", typeof(ExportNetlistDialog).name());
stdout.printf("Registering %s\n", typeof(NewDesignDialog).name());
stdout.printf("Registering %s\n", typeof(NewProjectDialog).name());
stdout.printf("Registering %s\n", typeof(RenumberRefdesDialog).name());
stdout.printf("Registering %s\n", typeof(ResetRefdesDialog).name());
stdout.printf("Registering %s\n",
typeof(BackannotateRefdesDialog).name());
Cheers,
Ed
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
On Wed, 2014-06-11 at 16:54 +0800, Nor Jaidi Tuah wrote: > Is there any way to declare a volatile? > Gedit highlighting indicates that it is a keyword in vala. > But trying > > volatile int xx; > > gives a compiler error. > > > Nice day > Nor Jaidi Tuah > As a side question - why do you need volatile? In most cases it's not needed (unless you write kernel/driver and do memory based I/O). Best regards signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable
you can try to create a vapi file with
[SimpleType]
[IntegerType]
[CCode (cname = "volatile_int_t", cheader_filename = "volatile.h",
has_type_id = false)]
public struct volatile_int_t {
}
and a volatile.h with
typedef volatile int volatile_int_t
2014-06-11 10:54 GMT+02:00 Nor Jaidi Tuah :
> Is there any way to declare a volatile?
> Gedit highlighting indicates that it is a keyword in vala.
> But trying
>
> volatile int xx;
>
> gives a compiler error.
>
>
> Nice day
> Nor Jaidi Tuah
>
>
>
>
>
>
> PRIVILEGED/CONFIDENTIAL information may be contained in this message. If
> you are neither the addressee (intended recipient) nor an authorised
> recipient of the addressee, and have received this message in error, please
> destroy this message (including attachments) and notify the sender
> immediately. STRICT PROHIBITION: This message, whether in part or in whole,
> should not be reviewed, retained, copied, reused, disclosed, distributed or
> used for any purpose whatsoever. Such unauthorised use may be unlawful and
> may contain material protected by the Official Secrets Act (Cap 153) of the
> Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of
> Brunei Darussalam, accept[s] no responsibility for loss or damage arising
> from the use of this message in any manner whatsoever. Our messages are
> checked for viruses but we do not accept liability for any viruses which
> may be transmitted in or with this message.
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] volatile variable in vala
Hi, 2009/12/28 Nor Jaidi Tuah : > Is volatile supported in Vala? I think it should. > If so, what's the syntax? I guess volatile type identifier; but it seems not to be working now, someone needs to fix it. (if there is no bug about this bugzilla, please file one) HTH, Abderrahim ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
