Hi all.

I need to implement a system wide locking system in all WIn32, Win64, Linux32 and Linux64. Therefore I need some king of named locking objects. For Windows I can use mutexes. For Linex I can only use sem_t structures managed by a series of functions in pthrlinux.inc but they are unnamed which means that they are only usable inside a multi-treaded process and not system wide.
Something else I miss ?

Antonio.

Why not just use a file ?

-Michael

Because speed is an issue.

I found TEventObject in syncobjs.pp
Only one question: are these objects managed by the OS and kept system wide ?

Le 08/02/2012 14:26, Michael Schnell a ?crit :

A FileStream isn't enough? Maybe use a FileStream and don`t go far the disk.

Michael Schnell wrote

Why not just use a file ?

Is there a cross platform file locking solution in fpc?

Henry

Le 08/02/2012 14:51, Everton Vieira a ?crit :

A FileStream isn't enough? Maybe use a FileStream and don`t go far the disk.

No because my funcion cannot deal with exceptions and cannot rely on them.

the old school simple solution is to just use a file... no need to get fancy... if the file exists or not is all you need to worry about :)

Henry Vermaak wrote

On 08/02/12 13:26, Michael Schnell wrote: > Why not just use a file ? Is there a cross platform file locking solution in fpc?

why would that be necessary is the simple existence of the file indicates locked or not??

Le 08/02/2012 19:58, waldo kitty a ?crit :

How much faster (or slower) is the file access vs. semaphore access ?

Le 08/02/2012 19:56, waldo kitty a ?crit :

Read my remark just above.

Le 08/02/2012 13:52, Antonio Fortuny a ?crit :

TEventObject in syncobjs unit does exactly the job. They are named and very fast, almost insignificant vs. program code.
They work across the whole system. So the resources to protect (quite small number) can have a named semaphore attached. This depends on the number of free semaphores.
For now tested in Win32 and Win64.
I'll port the same application undur Linx64.

Antonio.

Antonio Fortuny wrote

TEventObject in syncobjs unit does exactly the job.

The documentation on TEventObject suggest that it is for synchronizing multiple threads of a single process and not for synchronizing multiple independently running processes.

-Michael

Disk IO is one of the slowest memory usage that exists (even SSD drives). RAM is the fastest memory exists today.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120209/ff6f4f88/attachment.html>

ik wrote

Disk IO is one of the slowest memory usage that exists (even SSD drives). RAM is the fastest memory exists today.

That is why the OS uses a RAM cache and does Disk I/O only when viable.

-Michael

Le 09/02/2012 10:36, Michael Schnell a ?crit :

I've made a test on Win32 and the TEventObject is blocking system wide. Three instances af the same program are running (which means three independent processes) using the same named TEventObject. The first acquiring te event locks it for the two other whichever is the blocking process. This means that the TEventObject uses is managed by the OS at the kernel level.
I'll port the name test on WIN64 and Linux64 to see what happens. The documentation says:
"/Other threads that wish to be notified of these events should create their own instances of TEventObject with the same name, and wait for events to arrive/." which in turn suggests that any thread insterested in a names event must have its own instance of the object Anyway, it appears to work.

Antonio.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120209/81dc27b7/attachment.html>

The memory that is used by CPU caches is the fastest (but also the most expensive that's why it's only used for the relatively small caches).

Regards,
Sven

If I were you I'd first test it on Linux as soon as possible, because it might just be because of the Windows implementation that it works (the Windows and Linux implementations are completely different)

Regards,
Sven

Antonio Fortuny wrote

I've made a test on Win32 and the TEventObject is blocking system wide.

Great !

If this feature is really usable on all platforms, the documentation needs to be updated accordingly.

AFAIK:

System wide inter-process semaphores should be a lot slower than in-process inter-thread semaphores. With inter-Thread sync, for 99,99% of the calls, expensive OS-Calls (and thus context switches) can be avoided.

On Linux, there is FUTEX vs. MUTEX (I did a lot of research on this issue). Regarding Lazarus, for inter-Thread stuff (TCriticalSection and friends) Lazarus uses the pthread library which in fact does FUTEX (if available for the architecture it runs on, MUTEX otherwise). AFAIK, Windows also provides dedicated fast inter-thread mechanisms.

Thus it does make sense to use TCriticalSection for inter-thread stuff and those SyncOBJ functions, that are documented to be usable for inter-Process work, when necessary.

-Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120209/b19496dd/attachment.html>

Le 09/02/2012 11:02, Sven Barth a ?crit :

I know, it's planned for next monday.

Is there a way for a non-kernel-developer or plain FPC/Laz user to control what is stored in cpu cache ? I thought cache management is done transparently to userspace...?

L.

Only on IA-64 ("Itanic") as far as I know, and in any case for prefetches etc. to be effective the application code would have to be intimately familiar with the details of the hardware implementation. It's the sort of thing that would be a compile-time option on a Cray :-)

Yes, it's transparent. But my answer wasn't related to whether the memory can be controlled by the user or not, but whether it's the fastest or not.

Btw: In FPC you can use "Prefetch(SomeVariable)" to prefetch the data of the variable into the cache (if the platform supports something like that). See also:
http://www.freepascal.org/docs-html/rtl/system/prefetch.html

Regards,
Sven

Thought so ;) (disclaimer : I read lkml sometimes stumbling upon devs reordering paddings in structures to make them fit into cachelines)

L.

One of the best text (IMHO) you can read about what you can influence is: Ulrich Drepper's "What every programmer should know about memory"

Helmut

Which is a special case, since the kernel will have a fairly good idea of the platform's capabilities.

The first system I came across with a cache was one of these http://www.picklesnet.com/burroughs/images/fullsize/burr0116.jpg circa
1980. These days I've got things like Suns around the place, and it's pretty certain that any assumptions made about x86 cache architecture wouldn't apply to those since not only will line length etc. differ but so will the relative speeds of the connection between CPU and cache compared with cache and main memory.

But you're still likely to be screwed if the OS preempts between prefetch and use. Not only will the data have been flushed, but you've wasted the time executing the procedure.

typo alert! "necessary if the simple"

> locked or not?? How much faster (or slower) is the file access vs. semaphore access ?

once the file is in the cache, likely no difference in speed...

please explain what you mean by "semaphore access"... in the possible solution we're trying to point to, the file /is/ the semaphore...

i did and using a file as a semaphore to (b)lock or not seems fine... i use file semaphores in my stuff on numerous OS' and across numerous languages and scripting formats...

Michael Schnell wrote

On 02/09/2012 10:41 AM, ik wrote: > Disk IO is one of the slowest memory usage that exists (even SSD drives). RAM > is the fastest memory exists today. That is why the OS uses a RAM cache and does Disk I/O only when viable.

+1 and i indicated as such in my response written just a few minutes ago ;)

Yeah, read that.
Very good text.
Lukasz

Le 09/02/2012 19:10, waldo kitty a ?crit :

How much time to check a semaphore and a file

you still loose me... they are the same thing (to me) so there is no difference (to me)...

what, exactly, are you calling a "semaphore"? where, exactly, does it reside? how, exactly, is it created/removed?

How much time to check a semaphore and a file

Sorry I'll be more specific.
I need to solve a lock of a resource within a system accessed simultaneously by dozens (and hundreds in a near future) of processes. More specific, those processes can be either libraries linked to a program (static and dynamic) or independent programs. The resource lock has to be as fast as possible.
When the resource is unlocked, one and only one acquiring process can lock the resource again. I don't care about FIFO, LIFO or whatever. No other process has to run to guarantee the atomicity of the lock. I cannot rely on try ... except blocks because FPC versions on Win64 and Linux64 fail to keep a good control of exceptions flow (read issues http://62.166.198.202/view.php?id=12974 and
http://62.166.198.202/view.php?id=17280). To be honest I still have to re-test on Linux64.

Windows:
Events are not applicable: they help to lock on a system wide basis but fail to make the lock unique because the is no lock Mutexes appear to do the job. I've made a test with a dozen of processes on the same machine and only one of them succeeds to gain control of the mutex when it becomes free. The wait function locks immediately. One process at the time gains control over the resource an all processes do their job on the resource without data mix outide the rules. So, far so good.

Linux ?
I'm still looking for a solution equivalent to the Windows mutexes. Events seem to be local to a process.
Semaphores could be a solution but with Lazarus 0.9.31 on an OpenSuse 11.4 64 bit, semaphores can only be used unnamed (*sem_init* function is available) because function *sem_open* is not defined, only on DARWIN OS. The problem with a file is that I don't know how to use it as a semaphore with the above constraints.
The problem looks like a token problem.

Antonio.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120214/d5aed3a0/attachment.html>

On 14/02/2012 08:43, Antonio Fortuny wrote:

Hello Antonio,

System-wide solutions for Linux is the *Unix-way*, is to create a lock-file; If you create one on a tmpfs mounted directory, it will all happen in memory, hence no hard-drive storage access will happen (unless moved to swap, but in your case it won't ever happen) so all you need to do is check for lock file existence.
(IMHO)
There is also futex (Fast Userspace muTEX) but I don't know much about that one; http://en.wikipedia.org/wiki/Futex

HTH.
L.

Le 14/02/2012 10:32, Lukasz Sokol a ?crit :

Got it.

If you create one on a tmpfs mounted directory,

What do you call a "tmpfs mounted directory" ? I'm only a pascal programmer not a system guy

it will all happen in memory, hence no hard-drive storage access will happen (unless moved to swap, but in your case it won't ever happen) so all you need to do is check for lock file existence.

Does it mean that every process will have to create the file ? An open-close sequence checking the IOResult would be enough ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120214/85dc3403/attachment.html>

Lukasz Sokol wrote

There is also futex (Fast Userspace muTEX) but I don't know much about that one;

Futex needs a common user space for the code snippets that are to be synchronized, thus it is perfect for threads but not usable for system-wide stuff.

-Michael

Usually in /tmp, or by examining the output of 'mount'.

No, only the process that uses the resource, creates the file, that /i think/ should be enough, others only see if file exists.

Also, for other examples of inter-process communication, you may want to read about DBUS maybe ?

L.

Antonio Fortuny wrote

Linux ? I'm still looking for a solution equivalent to the Windows mutexes.

You can do this by storing the mutex in shared memory and accessing that shared memory from different programs. You have to set the mutex as recursive and shared (using pthread_mutexattr_setpshared). Look into the pthread man pages for info. I believe there's an example somewhere in the glibc sources, too.

Henry

Le 14/02/2012 11:22, Lukasz Sokol a ?crit :

No, all launched processes will have to do their work on the shared resource. In that way I wonder if an open on the control file with a deny share wouldn't work. This means that the locking algorithm must provide some kind of local loop in which a test is made with the open file and a sleep if the open fails. Something like (in pseudo-code) // do initializing stuff
while (not file error) and (not time elapsed) do begin open file (no share)

     if not open error then
         break;
     wait
     Dec(max time)
     continue

end;
if still file open error then begin
post an error message
exit
end;
// do whatever to do with the resource
// release clie (close it);

Also, for other examples of inter-process communication, you may want to read about DBUS maybe ?

Once something works I prefer to keep it as simple as possible.

How to use such an file?

Does it have to be created to indicate a lock, and deleted again when done?

Or is obtaining exclusive (r/w) access to the file equivalent to obtaining the lock?

The latter looks the right way to me, because then the lock will be removed by the system on termination of the owning process, be regular or aborted.

DoDi

Henry Vermaak wrote

Look into the pthread man pages for info. I

Usual pthread_mutex() functions are designed for working within a single process and thus will use Futex, if available and thus will not work system-wide. I don't know if pthreadlib offers an option for system wide Mutexes.

System 5 named semaphores (sem_open() and friends) are designed to work system wide and (AFAI remember) don't need any userspace memory resources.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120214/9468261a/attachment.html>

Al 14/02/2012 10:32, En/na Lukasz Sokol ha escrit:

System-wide solutions for Linux is the *Unix-way*, is to create a lock-file;

There are other methods, see here:
http://www.ibm.com/developerworks/linux/library/l-ipc2lin3/index.html

Bye

Le 14/02/2012 12:15, Michael Schnell a ?crit :

Yeap. But *sem_open() *seems not to be in my current Lazarus installation. I could define it mysel AFAI know whivh libtaty to use.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120214/5268ba43/attachment.html>

No, you're wrong. Read the section named "Process Shared Memory and Synchronization" for an example of implementing an inter-process semaphore with a pthread mutex and mmap:

http://linux.die.net/man/3/pthread_mutexattr_init

Henry

Henry Vermaak wrote

No, you're wrong.

I did a lot of research on pthread_mutex.. and I do know that it uses Futex when the underlying system provides same (not all Linux implementations on all architectures do have Futex). Thus unless you take additional care it can't be uses in an inter-process was.

I don't doubt that it is possible to use pthread_mutex.. for system wide semaphores, but as it uses user space memory you (at least) need to provide shared memory for the processes in question (and thus do something that is not the "standard" usage of the pthread-library. I never tried this. But I did try system 5 semaphores (also with FPC) some years ago and this did work nicely.

If Futex (via pthreadlib) really does work, it of course is faster than system5 semas, as in most cases a context switch can be avoided.

-Michael

Michael Schnell wrote

System 5 named semaphores (sem_open() and friends) are designed to work system wide and (AFAI remember) don?t need any userspace memory resources.

sem_open() is _not_ part of System V semaphores, it's part of POSIX semaphores and part of nptl. It uses futex internally.

Henry

yes, this is basic semaphore signaling...

Or is obtaining exclusive (r/w) access to the file equivalent to obtaining the lock?

in some cases, this may need to be done... i actually have some /old/ (TP/BP6/7) code (around) here (somewhere) that allows for "synchronized semaphore" work in that when the file is created, it is created with a specific number of bytes... the first process to acquire the semaphore opens it with read/write/denynone and does a region lock on the first byte... this allows another process to also acquire the semaphore and wait to lock the first byte... during this wait period, it has locked the second byte... when it can lock the first byte, it does so and releases the second byte... same thing for a third process except that it uses the third byte while waiting for the first one... basically the syncing comes from an orderly access... a process must also determine which byte is the last locked so that it can take the next one and not step in front of another process by snatching up an earlier byte...

the above worked great for the problem it was designed to solve but that problem could also have been handled by a simple semaphore design... one of the problems that was run into was when more than one process attempted to create the semaphore file... there needed to be a random delay inserted for the next attempt so that two or more processes didn't sit in a spin loop beating on each other trying to get the file...

The latter looks the right way to me, because then the lock will be removed by the system on termination of the owning process, be regular or aborted.

this can be done but i have seen problems where files and regions were left locked when the app crashed... in those cases, the only fix was a reboot...