What is the Black Board memory area?

Simply stated it is a special area of memory into which you can create variables that can be used by mulitple processes, (global variables if you will). By default all data inside the CLIPS DLL is isolated to the process which loaded the DLL, (note: I said PROCESSES not THREADS - threads share the same data as their process) This means I could have two or more processes each using the DLL at the same time and all running differing rules, etc... What if I want to share some of that information between these processes? This is the way to do that, by use of a 'shared pool' of memory between the processes. Note that the shared memory will be implemented whether you use it or not,, it should have a minimal effect on the amount of real RAM CLIPS needs as this shared pool is allocated directly from the swap file.
 

Note!

You must have JavaScript enabled for these web pages to function properly.

The following CLIPS functions have been added to the DLL version, (32 bit only):

  • set-strshare
    • parameter 1: Name of variable (STRING or SYMBOL)
    • parameter 2: value to set (STRING or SYMBOL)
    • returns BOOL (non-zero if it worked)
  • set-intshare
    • parameter 1: Name of variable (STRING or SYMBOL)
    • parameter 2: value to set (INTEGER)
    • returns BOOL (non-zero if it worked)
  • set-fltshare
    • parameter 1: Name of variable (STRING or SYMBOL)
    • parameter 2: value to set (FLOAT)
    • returns BOOL (non-zero if it worked)

     

    Each of the above routines sets a given value into the Black Board memory area. Once set, any process can access the value of this variable with the apporpriate get-? command. The get commands all return 0, (or NULL for the string), if the variable does not exist. ******************************************************************************
  • get-strshare
    • parameter 1: Name of variable (STRING or SYMBOL)
    • returns STRING
  • get-intshare
    • parameter 1: Name of variable (STRING or SYMBOL)
    • returns INTEGER
  • get-fltshare
    • parameter 1: Name of variable (STRING or SYMBOL)
    • returns FLOAT Above routines read a value from the BlackBoard area.

The get commands all return 0, (or NULL for the string), if the variable does not exist. ******************************************************************************

  • free-shareobj
    • parameter 1: Name of variable (STRING or SYMBOL)
    • returns BOOL (non-zero if it worked)
    • Frees an object from the BlackBoard area, (deletes it), attempts to free the associated memory block in the BlackBoard area. Since the default routines are targeted for 'quick-n-dirty' some garbage may collect.
  • get-shareslak no parameters...
    • returns LONG
    • Returns the ammount of 'garbage' space in the shared pool.Since the default delete is targeted for 'quick-n-dirty' some garbage may collect, (memory marked as used in the shared pool that is actually empty of any data).
  • defrag-share no parameters...
  • returns BOOL (non-zero if it worked)
  • Forces 'garbage' collection on the shared pool. Note that this will automatically occur if the slack gets high enough... If you did not have enough slack space to trigger the auto garbage clooection, and still failed when trying to set a *LARGE* variable, it might be worth the trouble to force garbage collection to see if you can then add it.

Some specifics on the shared pool itself:

  • Size: 65535 bytes, (approx. 40k of this is actually usable for storing data)
  • Maximum size for a Variable Name: 11 characters (if you overshoot they will be truncated)
  • Maximum number of variables the shared pool can have total: 1024 (an arbitrary number)
  • Amount of 'garbage' at which collection will automatically occur: 20480 bytes (approx 50% of the usable size)
  • Amount of 'garbage' below which collection will NOT occur, (even if you ask): 1024 bytes (less than 5% of the usable space) [this was done to save time, it takes a fixed amount of time to rebuild the shared pool 'sans' garbage, and other processes will block access during this time, so we do not want to do it if it is not needed]

These are not hard to change, but do require a rebuild of the DLL at this point. If you need larger values, let me know, these seemed reasonable for what I wanted to use it for. Since the memory is actually allocated from the pagefile, it could easily be bigger, there are not limits other than ones I arbitrarily chose. ******************************************************************************

Here is a sample CLIPS Batch rotine to test this.... use the CLIPS Wrapper method CLIPSBatchStar() to execute this...

[all output routed to wdialog]

[testbb.bat]

(set_strshare "teststr" "This is a test of the shared pool")

(set_intshare "testint" 123)

(set_fltshare "testflt" 55.5)

(printout wdialog (get_shareslak) crlf)

(printout wdialog (get_strshare "teststr") crlf)

(printout wdialog (get_intshare "testint") crlf)

(printout wdialog (get_fltshare "testflt") crlf)

(free_shareobj "teststr")

(printout wdialog (get_shareslak) crlf)

(free_shareobj "testint")

(printout wdialog (get_shareslak) crlf)

(free_shareobj "testflt")

(printout wdialog (get_shareslak) crlf)

(set_intshare "testint" 321)

(defrag_share)

(printout wdialog (get_intshare "testint") crlf)

(free_shareobj "testint")

(printout wdialog (get_shareslak) crlf)